[Seeking Volunteers] Bench Testing! Our trip to the best results!

  • Moderator

    @Junkhacker said in [Seeking Volunteers] Bench Testing! Our trip to the best results!:

    oh, also, i disagree with george about how fast an “ideal setup” can be with a single GbE network and one unicast:

    Boy, who made Mr. Hacker grumpy today? ;-)

    While we all know this already, but the number show in Partclone (GB/m) is actually a composite score of network transfer rate, decompression rate, and the speed to write the image onto the storage media.

    In a typical 1GbE network if someone said they were getting between 6.0 and 6.7GB/m deploy rate, based on my experience I would say that’s normal.

    If we just look at the numbers, a 1GbE network has a theoretical maximum throughput of 125MB/s. In practice I see 110 to 120MB/s. So lets use 120MB/s x 60 seconds = 7.2GB/m. So a 1GbE link can only transmit a maximum of 7.2GB/m. So in theory its not possible to get a deployment rate faster than 7.2GB/m. Your video showed 10GB/m, how is that possible? That is because the partclone number is a composite number which also includes image expansion and writing to the storage media. If you have a fast target computer with a fast disk, the target computer can take that 7.2GB/m data stream, expand it and write it to disk just as fast as the data can get to the target computer.

  • @Junkhacker are you using any 10gb network appliance? or 1gb?

  • @Junkhacker looking into all messages. will reply soon just testing some things.

  • Developer

    oh, also, i disagree with george about how fast an “ideal setup” can be with a single GbE network and one unicast:

  • Developer

    @george1421 we did a bunch of testing to compare pigz to zstd back when we decided to include zstd compression in fog.
    I had found the optimal setting for pigz in my environment was compression at level 6, and the optimal for zstd was level 11.
    comparing those 2 optimal settings against each other.
    10% faster capture speed
    26% smaller files were produced from capture
    deployment was 36% faster.

    zstd was early in it’s development and adoption back then and has had some changes to actually improve on it’s compression and speed since those tests were done, but we don’t know exactly by how much.

  • Moderator

    @Mokerhamer I did do some initial benchmark testing back in 2017 and I documented it here: https://forums.fogproject.org/topic/10459/can-you-make-fog-imaging-go-fast

    I can tell you based on an ideal setup on a single GbE network with one unicast image you should see about 6.1GB/m using a modern target computer. On a 10GbE network I would expect between 13-15GB/m transfer rates. On a well maintained 1GbE network you can saturate that server 1GbE link with 3 simultaneous unicast deployments.

    AFAIK no one has done a study for a real comparison between pigz (gzip) and zstd compression settings.

    Within the FOG imaging environment the deployment speed is directly controlled by the target computer. The target computer does all of the heavy lifting during image deployment. The FOG server and the network only delivers the image stream to the target computer. The target computer then takes the data stream, expands it and then writes it to the local storage medium.

    For example I have a FOG server running on a Raspberry Pi3. I get 3 to 4 GB/m transfer rates on my home network. The bottle neck in this setup is the storage medium on the PI itself.

    If you want to take on the challenge to see what is possible, everyone would be grateful for your efforts. Your testing needs to be scientific in nature. Using the same target computer, same network port, same, same, and only change one variable at a time.

  • @fry_p
    All True, i honestly hesitated to post (It’s complex to set-up…). But still lets share as much as possible.

    For example: Finding “goldilocks” Compression value for Partclone ZSTD.
    For example: We made changes to our Cisco network to go from 3/4GB -> 5GB Deployment – 1/2Gb increase! Why not share the changes we made to our cisco appliance with hardware info so others can benefit?

    Rather to much information on forum then to few is my mentality.

  • Moderator

    Though I like the enthusiasm, it may be my pessimistic nature talking, but I think there are too many variables to properly “benchmark” FOG. FOG’s claim to fame is how versatile it is, running on many different distros on very different hardware, going along very different network types and scales, etc. Even building a reference image can differ greatly. Unless you have the exact same type of disk (NVME, SATA SSD, Spinner) with the same exact version of the OS with the same procedure to set up said image, you will get the “dirty” results. So even if you have everything procedurally and hardware-wise replicated from test to test, you will only be bench marking that particular procedure and hardware. So if some other user with an entirely different setup was to look at your benchmarks without understanding this caveat and got different performance, he/she may think something is wrong. Just my two cents.

  • space holder for details! Comming soon

Log in to reply