100mb/s speed limit, please help

[stowtwe]

@Tom-Elliott

All of our connections are gigabit running to the computers we are trying to image. The only connection that is 100Mb is the line running from the switch to our router, but that should be irrelevant in this case because the packets do not need to go through the router to reach the hosts we are imaging. This WOULD be a bottle neck if we were imaging to other rooms in the building.

Here is a picture (There is another switch before the router, but you get the idea):

@george1421 Compression 9 was much slower than the others. I have also just recently tried compression 3, and it yielded similar results to compression 1 or 0. I will be trying 6 next to see how it goes.

[Tom Elliott]

THat’s why we need to narrow what and when and where things are happening.

Just because you “know” doesn’t mean that it couldn’t be doing something unexpected.

Seeing as it consistently showing the same results, it leads me to believe there is a 10/100 connection somewhere between. Maybe the imaging computer is on a different subnet than the fog server? If it is it would have to pass through the router and back to reach the fog server to begin with.

[Tom Elliott]

Also,

Could you try a TOTALLY different system and image it to see if you see the same limiting factors?

What are the systems that you’re seeing get the 100mb/s issues (specifically)? Age, nic, bios, etc… as possible?

Are the host’s nic Gigabit or 10/100?

There’s a lot of variables, and testing the same systems over and over seems a bit much to try to find a good solution.

Maybe let’s take out the problem systems for now and find out if it is indeed network, or system.

[george1421]

@Tom-Elliott Looking back over this thread I have a question for Tom, actually a confirmation is all I need. Does image deployment use NFS to move the file from the server to the client?

@stowtwe You have done tests with ftp and iptraf which received expected results. Did you do those tests between the FOG server and the same network jack where these target devices are connected?

Lastly, we haven’t considered that both the OP and Tom is right. Lets assume that for some reason the target computers are only functioning in 100Mb/s mode instead of GbE. This would make both people correct. With an unmanged switch it would be difficult to tell, maybe from the lights on the front of the switch.

Something else to consider is just change out the switch to a different model to see if there is something in the switch going wrong.

[Edit] I see that Tom was thinking along the same lines as it could possibly be the nic too. it just took me a bit for my last post [/Edit]

[Wayne Workman]

@george1421 Imaging uses NFS.

NFS is utilized for upload and download.

/images is mounted as read-only via NFS for download.

/images/dev is mounted via NFS as read/write for upload (after upload completes, FTP is used to move the image from /images/dev to /images)

Settings for NFS can be found in /etc/exports

Here’s a related article with lots of good commands and info in it: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_NFS

[stowtwe]

@Tom-Elliott The issue was with subnetting. We combined 2 subnets not long ago, and the server still had the old subnet mask. I changed the mask and it now is seeing everything on the same network as it should. I am getting 3-4 GB/min now, MUCH faster than before.

Thank you everyone for the help. This was something I should have been able to catch, and was definitely not a direct problem with FOG.

[Sebastian Roth]

What on earth has subnetting to do with speed? I am not convinced that this issue was fixed by changing the subnet mask on the FOG server. Well, only if the wrong subnet mask would make the server send all the traffic over a gateway to the client(s) which would then have been the bottleneck. But… Anyhow, great you got this fixed.

[Wayne Workman]

@Sebastian-Roth said:

What on earth has subnetting to do with speed?

That’s what I thought. But if it’s fixed it’s fixed.