PCI-e bandwidth/capacity limitations

A forum for discussing FAH-related hardware choices and info on actual products (not speculation).

Moderator: Site Moderators

Forum rules
Please read the forum rules before posting.

Re: PCI-e bandwidth/capacity limitations

Postby Sven » Mon Aug 14, 2017 3:49 pm

It's like you say. There is no Chip/Logic on the USB risers. It's just cheaper to use standard cable an connector types.
Sven
 
Posts: 33
Joined: Fri Nov 01, 2013 8:12 pm

Re: PCI-e bandwidth/capacity limitations

Postby hiigaran » Wed Aug 16, 2017 6:11 pm

So, I purchased a pair of risers a while back, and started testing them out. Unfortunately, I haven't been able to even get to the testing stage, since I'm having issues getting the cards to fold at all in the first place.

Those of you with riser experience, any help? System setup is is currently:

2x GTX1080 connected directly via x16
1x GTX1080 connected via x1 USB powered riser
Linux Mint 18.2, kernel 4.11

What I know so far:
1: Power is not an issue. The system usually runs 4x 1080s directly off the slots
2: GPU is not faulty. In the standard hardware configuration, they run and fold just fine
3: Slots aren't faulty. Wouldn't work under standard configuration otherwise

No matter what happens, POST completes successfully, and all attempts to boot would get me at least to the OS loading screen. While running the slots at Gen3, the system freezes shortly after loading the desktop. F@H has not started at this point, so high load would not be the cause. The few times it had successfully started up, X Server does not detect the GPU on the riser. However, running the slots as Gen2 consistently results in a successful boot, and the riser card shows as detected.

This is as far as I can get. While my system is in this testing configuration of three cards, FAHClient does not start, and FAHControl is stuck trying to connect. Manually starting FAHClient will let FAHControl connect, and I am shown a message saying I need to configure my identity, similar to the first time one installs F@H. Naturally, I need to reconfigure my slots, which seems to work, until the work units start downloading. All of them immediately show bad work units, including the non riser cards.

I still don't know if the risers are faulty. Seems unlikely that both would be. And having all work units fail, riser GPU or non riser GPU, just raises further questions. Returning the system back to its original quad card configuration reverts everything back to normal, including the work units and slot configs from before the testing. At least that was convenient!

So what do you guys think? How should I proceed? I'm still set on doing a whole heap of testing to make these comparisons.
User avatar
hiigaran
 
Posts: 104
Joined: Thu Nov 17, 2011 6:01 pm

Re: PCI-e bandwidth/capacity limitations

Postby bruce » Thu Aug 17, 2017 3:19 am

When you start FAHClient, are you using the script that's provided with the install?
sudo /etc/init.d/FAHClient start
bruce
 
Posts: 21270
Joined: Thu Nov 29, 2007 10:13 pm
Location: So. Cal.

Re: PCI-e bandwidth/capacity limitations

Postby hiigaran » Thu Aug 17, 2017 6:09 am

I did not. All I did was type FAHClient. Can try that out later on though. What are the differences between the two?
User avatar
hiigaran
 
Posts: 104
Joined: Thu Nov 17, 2011 6:01 pm

Re: PCI-e bandwidth/capacity limitations

Postby bruce » Fri Aug 18, 2017 6:20 am

FAHClient is designed to run as a service. The script is SUPPOSED to install itself so that FAHClient start at boot time (just like other services)and run forever. FAHClient doesn't actually process anthing except commands from either FAHControl or WebControl, and if you want it to be idle, you manage that also from either of those control programs.

The script runs it as another Linux user, not as you, and it has its own set of permissions.

The configuration is also managed by *Control, NOT by an editor.
bruce
 
Posts: 21270
Joined: Thu Nov 29, 2007 10:13 pm
Location: So. Cal.

Re: PCI-e bandwidth/capacity limitations

Postby GPU timpster » Sun Sep 03, 2017 4:43 am

bruce wrote:FAHClient is designed to run as a service. The script is SUPPOSED to install itself so that FAHClient start at boot time (just like other services)and run forever. FAHClient doesn't actually process anthing except commands from either FAHControl or WebControl, and if you want it to be idle, you manage that also from either of those control programs.

The script runs it as another Linux user, not as you, and it has its own set of permissions.

The configuration is also managed by *Control, NOT by an editor.


I'm also doing the "FAHClient" in a terminal because I cannot see "folding@home" in the OpenSUSE menu. I know that's a completely different issue, but, what would be the downside to running in the terminal (and seeing extra info using the control software)? Also, because "folding@home" is not listed in the menu, (and that I purposely broke the install, not having "bzip2-libs") would this be the reason that it is not (I assume) starting at boot?
GPU timpster
 
Posts: 54
Joined: Mon Nov 02, 2015 2:57 am

PCIe lanes and PPD

Postby A_random_ai » Mon Sep 11, 2017 3:03 pm

Mod: merged with existing topic - j

Is there a PPD difference in a GPU at x16 PCIe 3.0 vs x8 PCIe 3.0?
A_random_ai
 
Posts: 1
Joined: Wed Sep 06, 2017 1:20 pm

Re: PCI-e bandwidth/capacity limitations

Postby Nathan_P » Mon Sep 11, 2017 5:16 pm

about 1-2% from my tests
Image
Nathan_P
 
Posts: 1701
Joined: Wed Apr 01, 2009 9:22 pm
Location: Jersey, Channel islands

Re: PCI-e bandwidth/capacity limitations

Postby v00d00 » Mon Sep 11, 2017 8:46 pm

GPU timpster wrote:
bruce wrote:FAHClient is designed to run as a service. The script is SUPPOSED to install itself so that FAHClient start at boot time (just like other services)and run forever. FAHClient doesn't actually process anthing except commands from either FAHControl or WebControl, and if you want it to be idle, you manage that also from either of those control programs.

The script runs it as another Linux user, not as you, and it has its own set of permissions.

The configuration is also managed by *Control, NOT by an editor.


I'm also doing the "FAHClient" in a terminal because I cannot see "folding@home" in the OpenSUSE menu. I know that's a completely different issue, but, what would be the downside to running in the terminal (and seeing extra info using the control software)? Also, because "folding@home" is not listed in the menu, (and that I purposely broke the install, not having "bzip2-libs") would this be the reason that it is not (I assume) starting at boot?


Can't help you on the bzip2 issue, but generally you can add them using whichever package manager comes with your distro (common ones are yum, apt, pacman).

As for running it on the console, their isn't really any downside. The client will still offer you the web interface for checking on it, stopping/starting. Although personally I would recommend some sort of startup script that launched it using screen and checked the client was still running every minute or so. If you want to learn how to do that, have a look for a game server startup/check script, then modify it to look for FAHClient instead and add it to crontab with a check every minute.

Or you can use something like this if you wish.

checkfah.sh
Code: Select all
#!/bin/sh

process=`ps auxw | grep FAHClient | grep -v grep | awk '{print $13}'`

if [ -z "$process" ]; then

  echo "Couldn't find FAH running, restarting it."
  cd /path/to/fah
  nohup screen -DmS fahgpu ./FAHClient &
  echo ""

fi

exit


EDITOR=nano crontab -e
Code: Select all
0-59 * * * * /path/to/checkfah.sh 1> /dev/null


You obviously need screen installed. But the above will launch your fahclient in a detached screen which you can reattach from any console using
Code: Select all
screen -r fahgpu


To detach it again, hold down Ctrl and tap 'A' then 'D.

If you have issues re-attaching and have fah running under a fah user or different user and have switched to that user using 'su -' Then run the command
Code: Select all
script /dev/null
before re-attaching.
Image
User avatar
v00d00
 
Posts: 502
Joined: Sun Dec 02, 2007 4:53 am
Location: In the UK

Re: PCI-e bandwidth/capacity limitations

Postby QuintLeo » Tue Sep 12, 2017 11:30 pm

It has been tested and shown that a PCI-E 2.0 8x slot has a noticeable negative performance impact on FAH work vs a PCI-E 2.0 16x slot OR a PCI-E 3.0 8x slot.
PCI 3.0 8x and 16x AT THIS POINT seem to have no significant performance difference even on Pascal-based Titan and GTX 1080ti cards.

For reference - a rig I built a couple months back was using a G4600 (dual core WITH hyperthreading Kaby Lake Pentium) and a pair of GTX 1080ti cards - and it was CPU LIMITING both the 2 actual cores AND the 2 "hyperthreading cores" on many work units, and very very close on the rest.
THAT MUCH DATA.

Cryptocoin mining doesn't involve nearly as much data, which is WHY you can get away with 1x riser rigs with no noticeable performance impact, and can run multple GPUs on old single-core CPUs like the Sempron 145.
This would also apply to a some BOINC work (Moo Wrapper in specific, probably Yoyo as well, not sure on other projects).
QuintLeo
 
Posts: 39
Joined: Sat Jun 17, 2017 5:43 am

GPU folding on PCI-e 2.0 and 1.0

Postby Alezz95 » Thu Sep 14, 2017 9:49 am

Mod note: merged with existing topic in appropriate sub-forum - j

Hi. I wanted to know if there are problems folding with a PCI-e 3.0 GPU put on a 2.0 or 1.0 slot, or if the tasks will slow down. Thanks.
Alezz95
 
Posts: 1
Joined: Thu Sep 14, 2017 8:08 am

Re: PCI-e bandwidth/capacity limitations

Postby foldy » Thu Sep 14, 2017 4:37 pm

What GPU do you have and what mainboard? PCIe speed is given in gen like 3.0 and speed like x4, what do you have? PCIE 3.0 has double speed than 2.0 than 1.0 PCIE limits mainly occur on Windows. Linux has only marginal limits.
foldy
 
Posts: 909
Joined: Sat Dec 01, 2012 3:43 pm

Previous

Return to FAH Hardware

Who is online

Users browsing this forum: Google [Bot] and 3 guests

cron