Fooling around

[darkone]

Testing some algorithms for the new core... (fully asynchronous handling of sockets/files/pipes/....)

Single transfer looks something like:

Read
Read
Written
Read
Written
Written
Written
Read
Read
Read
Written
Written
Read
Written
Read
Written
Read
Written
Read
Written
Read
Written
Read

... ordinary file transfer usually looks like:

Read
Write
Read
Write
Read
Write


Advantages? I can disable both socket and file buffers, for maximum scalability & performance. Notice that on large fat32 partitions it will result to worse scalability, because minimum buffer size for unbuffered file reads/writes is size of one cluster. Using 5transfer buffers, means 32kb*5 bytes per filehandle. (it also increases amount of memory copying etc...) => upgrade to ntfs for optimal performance :)

[Luke]

You done reading yet ?. Can we borrow it ?

:banana:

[darkone]

Borrow what? .. I think I missed something :) Read/write routines for transfering between two handles are nearly complete. I'll start working on adding ssl implementation next week.

[darkone]

Whew, I had some serious error in my algortih (something one couldn't even consider as a bug :~) It seems, I was able to resolve it without noticable effect in performance... now each handle uses four locks to guard counters & buffer queues. (and that's a lot... 16bytes of mem ;))

I did some performance tests with single thread.. and so far, results are far beyond my expecetations:

On 10mb/sec transfer over network results are following:

Wait: 9.48972774seconds Work: 0.43205802seconds

Which leads to theoretical maximum output of: 10mb/sec * 9.48972774secs / 0.43205802seconds = ~210mb/sec on single CPU system... assuming that after bandwidth limits, timeouts, etc. I get even half of the theoretical maximum, it should be breaking the 200mb/sec barrier that I set for my computer.