Another Slow Upload and Download Speed Thread
-
One last test, please.
Did you do the Iperf test from the troublesome client?
If not, can you re-run the Iperf from that client to the FOG server and post those speeds?
Thanks.
-
Kernel used doesn’t matter for right now. I doubt it’s a kernel issue anyway. To get the kernel version, you’d need to boot client system into debug and run [code]uname -rm[/code]
What I’d like to see is the client being on the same switch as the FOG Server first. This will let us know whether it’s FOG or not. Nothing much has changed in fog that this randomly started being a problem.
There are many variables to consider though. Compression on the image is only impacting for image uploads, not downloads. If the image was originally uploaded at max, it will remain max compressed until you reupload the image at a different compression rating. I’m smart but I’m not that good.
One of the things to consider in the compression vs. upload/download ratings though is finding the goldilocks balance of the two. I’ve typically found an image at 5 or 6 compression seems to give the best download AND upload speeds. 3 is what prior versions of FOG was set to. This works in two ways. The upload doesn’t have to work AS hard to compress the image therefore it finishes faster. The download goes faster because there’s ultimately less data to transfer over the network and the client can relatively easily de-compress the image.
-
I will do the test on the same switch tommorow.
Compression was on 3 so it is still at 3. We have never touched the compression, so this can’t be an issue.
-
[quote=“Polii123, post: 44685, member: 28818”]I also put down compression, but that didn’t change anything.
Im on SVN 3178.[/quote]
Am I mistaken?
-
I meant we didn’t touch the compression before the problem occured.
Iperf result on the testing client, is the same as the one i posted.
-
I agree with Tom, that you should try to image /w the client on the same switch as the FOG server.
Speed may not be the issue, but something else might be. Eliminating variables in the problem is the name of the game.
-
The device you’re using, T540p, isn’t listed in the problematic devices or working devices, in the WiKi.
Are you experiencing the slow imaging speeds on every client? Or just clients of this model?
-
Every client. T540p also was on 5GB/min.
-
what network card is in that computer?
-
Intel Ethernet Connection I217-LM
-
Just thought of something…
Could you do a health-test on the FOG server’s image storage drive?
If it’s failing, that will explain what you’re seeing.
-
Maybe this can give us some more insight?
-
bump…
Any updates on this?
-
The quality of the switch can make a tremendous difference as well. Recently we replaced 10/100 Allied Tellison switches with 10/100/1000 HP ProCurve Switches in a laboratory environment. Incredible difference in reliability of transmitting and recieving, as well as bandwidth with multiple synchronous images
-
Hi,
There is a simple tools to check the bandwith of your network : [url]https://iperf.fr/[/url]
A java frontend here : [url]https://code.google.com/p/xjperf/[/url]You can test TCP/UDP bandwith.
I use it before deploy in multicast.
Regards,
Ch3i. -
Sorry I was sick over Easter thats why i didn’t write here.
I contected the client directly to the core switch today, but that didn’t change anything.
-
Have you checked the server’s hdd health ? Checked the RAM health?
-
How can I do that?
-
I found this: [url]http://unix.stackexchange.com/questions/124790/how-to-check-health-of-hard-drives[/url]
But if it were me, I’d probably shutdown the FOG server, and boot up to the latest version of Hiren’s BootCD. Normally you have to find a torrent of it and download it that way. It comes with a SLUE of utilities.
If the hard drive is failing, that’d explain your speeds during imaging.
-
Ok, will try that on monday.
