We can not know - performance is very very dependent on programming its network stack "from outside" of the chip. That's why I request technical details.
edoz wrote:
At least the buffering part of the w5100 could sometime have some strange behaviours as well.
I need to know the details. How do you access the chip - through GR8NET API or directly? Did you make Wireshark logs to see what is going on the network?
(I think separate thread is required for this issue if you still can reproduce it)
edoz wrote:
On the other hand, if I look to the gr8net cloud solution im very surprised by the speed.
I think Denyonet has a few shortcomings due to its design.
Not sure if it is hardware or software design, but the UNAPI code for it depends entirely on VDP interrupts. So, FTP has a block receiving, wait ack, block receiving, wait ack, block is. 512 bytes... At 60Hz interrupts, this will limit the performance of acking / receiving, and thus why R800 won't help improve performance, the 60Hz (or 50Hz) interrupt is the performance limiting factor in this case.
So, I believe that not having its own interruption (be it from w5100 or another hardware generated interrupt schema) limit Denyonet performance, at least this is what I remember looking at the source code of DENYONET TCP/IP UNAPI BIOS implementation.
