Compressing or not compressing during sequencing has benefits and disadvantages:-
Compressed. The sequenced stream will be smaller; this can be useful where storage is of concern, or more probable, where the network utilisation is of concern. Compressing the sequence reduces the quantity of data streamed over the network to each client machine, this means it will be delivered faster and utilise less bandwidth.The disadvantage of compressing is that the decompression on the client computer is processor intensive and can increase the initial launch time.If you plan to use compression it is recommended that testing on the lowest performing target machine is performed to ensure acceptable usability.
Not Compressed. This is the default and recommended unless the network is deemed excessively slow.
TIP: bZip2 uses less processor cycles to decompress than zLib and is therefore uses less power, is faster, and can process more data, this has the benefit of a higher bandwidth throughput. Testing should always be performed to optimise for your scenarios.
Block SizeBlock size is specific to Feature Block 2 (FB2) as feature block 1 is streamed as a single entity. When the client requests data from FB2, the size of each block determines the amount of data that can be streamed in a single transaction. The larger the block size, the more data is streamed in one transaction and as a result, network utilisation is increased; for smaller block sizes, less data is streamed in one transaction and this reduces the network utilisation.There is a balance needed between large and small block sizes where the amount of data in any block compares to the request of the client. Larger blocks can contain more useful data in one block, but this may be more than required, whereas smaller blocks are more likely to contain the useful data but more will be required and each has a network overhead. Over the years of testing with SoftGrid, the default 32KB has been found to be the best balance of the two.
TIP: Block size can directly influence compression using bZip2 and zLib and should be tested using different block sizes when compression is used.
Hi, good Info. But one thing is not clear for me. If you use Compression and a TS Client, when will the package decompressed ? During or after streaming ? May during runtime ?
Greetings from Germany
The decompression takes place inside the TS session. Normally TS sessions are classed as 'connected' and I wouldn't normally expect compression to be used for that scenario.
Hello, nice article. I tried to use bzip2 independently but ended up with a corrupt sft-file. Is it possible to compress sft files outside of the sequencer?