[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Fwd: upgrade to jessie from wheezy with cuda problems



On Sun, Nov 17, 2013 at 10:45:58AM +0100, Francesco Pietra wrote:
> I am attacking the problem from another side, directly from within the OS
> itself:
> 
> #lspi -vvvv
> 
> tells that the link speed (= link status) "LnkSta" is at 5Gb/s, no matter
> whether the system is at number crunching or not. I.e., my system is at
> PCIe 2.0. This might explain why upgrading from sandy bridge to ivy bridge
> gave no speed gain of molecular dynamics. PCIe 3.0 was not achieved.
> 
> As far as I could investigate, nvidia suggests to either:
> (1) Modify /etc/modprobe.d/local.conf (which does not exist on jessie) or
> create a new
> 
> /etc/modprobe.d/nvidia.conf, adding to that
> 
> 1. options nvidia NVreg_EnablePCIeGen3=1

Might need nvidia-current instead of nvidia.

> Actually, on my jessie, nvidia.conf reads
> 
> alias nvidia nvidia-current
> remove nvidia-current rm mod nvidia
> 
> 
> Some guys found that useless, even when both grub-efi and initramfs are
> edited accordingly, so that nvidia offered a different move, updating the
> kernel boot string, by appending this:
> 
> 1. options nvidia NVreg_EnablePCIeGen3=1
> ***************************

That is NOT the syntax for a kernel command line.  It is the syntax for
the modprobe config.

Something like nvidia.NVreg_EnablePCIeGen3=1 or
nvidia-current.NVreg_EnablePCIeGen3=1 (depending on the name of the
module as far as the module is concerned).

> I did nothing, as I hope that the best adaptation to jessie may be
> suggested by those who know the OS better than me.
> The kind of information about links includes:
> 
> LnkSta: the actual speed
> 
> LnkCap: the capacity of the specific port, as far as I can understand.
> 
> LnkCtl: ??
> 
> 
> One could also run
> 
> #lspci -vt
> 
> to determine the bus where the GPU card is located, then running
> 
> # lspci -vv -s ##
> 
> where "##" is the location.
> ******************************
> 
> So, it is a tricky matter, but perhaps not so much when one knows where to
> put the hands. At any event, being unable to go to 8GT/s, as from PCIe 3.0,
> means loosing time and energy (=money and pollution), at least when the
> GPUs are used for long number crunching.

Well it means slower transfers of data to and from the card.  If the data
set fits in the card entirely during a long number crunch, then bandwidth
would not matter much at all.  So depends on the size of the data set
and how often data has to be moved in and out of the card.

> I'll continue investigating. The above seems to be promising. Hope to get
> help.

-- 
Len Sorensen


Reply to: