Another upload/download speed issue



  • My colleges and I have noticed over the last couple of months that 2 of our images seem to upload at a faster speed than the others do and then in turn, deploy at a slower rate than the others. My FOG_PIGZ_COMP set at 9 and has always been set at this since I’ve had it. Ordinarily, my upload speeds are under 1GB/min, about 800 MB/min, and download speeds at around 3-4.5 GB/min. Right now, I have a computer uploading a 1.6-1.7 GB/min and will download at about 500-800 MB/min. What is causing these 2 images to be a different speeds than the many others that I have done. These 2 are some of the first ones that I created on my fog server.



  • @Wayne-Workman Yeah I know, me either…its a SanDisk 64 GB…SDSSDP-064G. I’m assuming it’s one of their first models. We bought them close to 3 years ago.



  • @the_duke said:

    @Wayne-Workman Ok, with the normal wipe finally completed, the deployment went through with speeds of an average of 5.57 GB/min which is what it should be and only took just over 5 minutes. I wouldn’t have thought the need to wipe it to start with. I figured that we were technically doing that when we were deploying out the image to it, but for some reason with the drive being that full to start with, the drive wasn’t write the image to the disk very fast I guess.

    That makes absolutely no sense to me… but OK lol.

    Care to share the exact model of the SSD ?



  • @Wayne-Workman Ok, with the normal wipe finally completed, the deployment went through with speeds of an average of 5.57 GB/min which is what it should be and only took just over 5 minutes. I wouldn’t have thought the need to wipe it to start with. I figured that we were technically doing that when we were deploying out the image to it, but for some reason with the drive being that full to start with, the drive wasn’t write the image to the disk very fast I guess.



  • @the_duke Nevermind, it just completed…didn’t remember it normally taking that long to do.



  • @Wayne-Workman How long should the normal wipe task take? It has been going for an hour and a half now and the screen shows writing zeros to /dev/sda and then a blinking cursor right below it. When I look in the task management in fog web interface, it just says the task is queued.



  • @Wayne-Workman Will do.



  • @the_duke We’ll see, I guess. Do report your findings.



  • @Wayne-Workman Ok, well I believe that I have found out the problem. These custom built units currently have 64 GB SSD on them. They were getting filled up and what we were trying to do was reimage them and to free up some space. What we probably should have done is at least a normal wipe of the drive and then reimaged the machine. What I tried was taking the HDD out of one of the refurbished units that was going normal speeds and hook it into one of the custom built units and it imaged in 5 minutes. So I am in the process now of doing a normal wipe of a machine and then going to reimage it then and see how it goes. I am expecting it to go much more normal.



  • @Wayne-Workman ok, I upgraded to trunk and I’m on version 6533. I uploaded my image just to make sure the image was updated with latest settings. The image uploaded in 9 minutes at a rate of 3 GB/min which is very fast. Now after finishing a download to another computer of the same model, it had an average rate of 729.39 MB/min. I had set my compression rate for this image at 7.



  • @the_duke The FULL new inits and newer kernels might make all the difference.

    And even if there’s no discernible difference with FOG Trunk, the developers will likely want to take a look and see what’s going on - since you’ll be on the latest developmental version and they need opportunities to test on new/unique environments.



  • @Wayne-Workman well ok, I’ll try that in the morning



  • @the_duke Well, since your so willing and keen on rebuilding your server - I say hold off and upgrade to FOG Trunk and see how that goes, first.

    https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_trunk



  • @Wayne-Workman Ok, I currently have undionly.kkpxe on dhcp server. I have also tried undionly.kpxe (which was on there originally), ipxe.kkpxe, and ipxe.kpxe. do you have any other suggestions?



  • @the_duke Well your using better compression settings, better inits, and the exact same 1.2.0 code base, and Your only experiencing this issue on a particular model of computer, the location/port doesn’t make a difference, and this is a recent thing.

    Those facts don’t compliment each other, not in my mind.

    You could go ahead and rebuild, but I doubt that any change on the server would effect it since the problem is specific to a particular model of computer.

    I’d say don’t change anything else on the server - don’t make any more changes to the kernel or inits or any of that.

    Just play with changing the boot file - that’s it. See how that goes.



  • @Wayne-Workman Ok, after trying several download tasks, I’m still getting nowhere. What had been taking 10 minutes at the most a month ago is now taking over an hour. Something has got to give…do I just need to try and reinstall fog or what’s the deal?





  • @the_duke I’m pretty sure the kernel update feature would overwrite the inits you downloaded earlier. You’ll want to get those again after each different kernel download for testing.



  • @Wayne-Workman Ok, I played around with a couple of other kernels and am now getting better download results so far with Kernel - 4.1.0 TomElliott. By better I mean it is so far doing about 24 minutes instead of the 1 hour as before. I’m trying different kernels right now to see if I can get it any better. I’m just guessing at this point.



  • @the_duke Your using the new inits. It’s totally possible that there is some fluctuation in upload times.

    What I’m really curious to see is how download performs with the new image.


 

344
Online

41.8k
Users

12.3k
Topics

116.0k
Posts