Another Slow Upload and Download Speed Thread
-
Hi
Our Fog Server Tasks are prettey slow if you compare the speed we have right now with the speed we had about 2 months ago.
At that time we had about 4.5 to 5 GB/min. Now we only have 1.4GB/min.
It can’t be network or the Fog Hardware, because i get 133MB/s and 285MB/s, with a NFS test write i found in a diffrent thread. I also put down compression, but that didn’t change anything.
Im on SVN 3178.
-
Are we talking download multicast or single imaging??
-
Single Task, but Multicast is also slower. 800MB/min instead of 3GB/min.
-
This sounds to me like somebody has got a 10/100 Switch in the way somewhere, or maybe a 10/100 NIC is on one of the devices?
-
There is no 10/100 Switch, i tested on the same cable. Device is a Lenovo t540p, but they had also higher speeds before.
Made a mistake, NFS test is only 34MB/s and 115MB/s.
-
What’s concerning me is that the speed difference seems to be the exact difference from a gig to 10/100 switch. This is why I ask the question.
If you can take out the “switch” as a factor and take one of these systems and place it directly on the same switch as the FOG Server, do the speeds increase?
-
A bad patch cable will make a NIC revert to 100 meg, or even 10 meg if it’s bad enough.
Have you only tested one client, or is this problem throughout your environment?
-
It is defently not the switch. The Fog Server is connected to the Core Switch, this one is contected with 1G Fiber and then there is a 8Port unmanaged switch (10/100/1000) and the there is my client.
BUt the Problem also occurs on diffrent diveces wich are contected to diffrent switches. So Network shouldn’t be the problem.
Also check the edited post above with the corrected test results.
-
new network equipment anywhere?
new router? Switch? Active and/or Passive Intrusion Detection System?
When was the last time the FOG server was rebooted? Is it virtualized?
Have you done simple stuff yet like re-seat the FOG server’s patch cable? Test the cable? Replace the cable?
Maybe something happened to it’s NIC? When was the FOG server’s last OS update? Maybe try a throughput test using [U][URL=‘http://en.wikipedia.org/wiki/Iperf’]Iperf[/URL][/U] ?
-
Network is still the same. Fog Server was rebooted 3 or 4 weeks ago. No it isn’t virtualized.
Iperf result:
[ 4] local 172.30.40.25 port 5001 connected with 172.30.40.90 port 47665
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 1.09 GBytes 936 Mbits/sec -
With that kind of throughput, you can eliminate the switch, patch cables, and NICs, and NIC drivers from the equation…
This is definitely something with FOG… Maybe FOG Configuration, Maybe the drivers that it’s distributing via the kernel… maybe…
What version of FOG are you using? what SVN version? What’s the model of the computer you’re testing the problematic imaging with? What kernel version are you using for the network booting?
-
Version is 3178. I’m testing with a Lenovo T540p.
Where can i look wich kernel is used?
-
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.
