Pyr0Mathic wrote:
the speed limit of 8 MB/s is when i use a Realtek 8139 100/10 Mbit ethernet device and if i am writing to the disk. and once the file operation is done which is in the above case: a file of 500MB the hdd also directly stops writing data, so the hdd write-buffer isnt writing data anymore almost directly.
also my motherboard is ATA33 and i got a 120 gig drive in there, which should atleast be ATA100 or 133. so the hdd shouldnt be the problem.
The ATA number indicates how fast your harddisk controller on the harddisk can send data to the IDE controller on the mainboard. As with all things, the slowest / weakest link decides the speed / strength. If you communicate to someone on Mars with a 100mbit ethernet card, a 300bps inter-planet link and a 100mbit network on mars, the speed will be 300bps even though you have a big fat network pipe.
Harddisk speeds are currently limited both by rotation speed and by seek times. Rotation speeds can't be avoided (you can't just speed up a harddisk, faster harddisks have lots of disadvantages and still people develop a 20krpm harddisk). You can avoid seek times. Read a full track each time, cache them, make sure you use most of those tracks - that increases the amount of data transferred per seek. Make short seeks, they're faster (since you don't have to seek far, you'll be synced sooner). In short, make sure you read locally.
but the encryption won't have a "codebook"-style to it.
what do u mean whit codebook-style?
Was thinking about using SSH for a secure connection, but havent really looked in to that yet. CBC does seem to be very usefull from what i can see on Wikipedia about it.
Codebook: you take any random block and it's encoded independently from the others, so you can look it up in a "dictionary" that tells you the answer to what it is. CBC = code book chaining, which means that each block is XORed with the previous encoded block before encoding, so that you cannot look up answers (and so that continuous repetitions will look very different). Because you take the encrypted version of the block to xor and then encrypt, you will get a very different output every time.
I come back on my statement that you can't seek. Since you have the key and the previous encoded block, you can just take that block and xor it on the decode to find the actual answer. Seeking is then also possible and minimally slower than without CBC (one XOR over 32 bytes, which should not take long).
Small note on implementation, afaik most recent processors have 64-byte cache lines. If you align your data to natural boundaries (32-byte alignment that is), you'll get quite better performance (since you will only use one cache line for the data at all times, you have more cache lines - more speed, if you use them all).