That's probably the firmware logic more than anything else. The original transmission routine was really bad about handling collisions, which are obviously super common on a hub. The current version should handle that situation better. I've got a Asante 10BaseT hub around here that would be...
Fantastic news! I'm really happy to hear that you didn't have any crashes. Those speeds are also quite good. Your FTP setup is obviously better than mine, that's 3x the read performance I'm getting and is much more in line with my AppleTalk speeds. All told, a very nice set of results, thanks...
Got the Dayna problem worked around and the fix is up on Github. Here's the flow, as far as I figure it:
The Dayna driver performs SEND MESSAGE on a fairly short packet.
The Dayna driver performs GET MESSAGE to check for inbound packets.
If scuznet immediately replies with a packet from the...
Ah, I should have said something about that: this system is running MacTCP, mostly due to how little RAM it has (5MB). I'll find some 4MB 30 pin modules and try OT. I'd be curious if my current Daynaport issues go away with it too.
That is really weird. This network is two computers: the IIsi...
I've flashed your firmware to my V1 board and ran some tests. For context, I'm running a fresh "this Macintosh" version of 7.5.3 on a IIsi, Daynaport 7.7.2, writing to the scuznet flash card with a volume image in 'forcefast' mode. The "server" is a Debian VM running vsftpd on my desktop. It...
The TCP bursts are big and short, so maybe throughput is less important than latency? Not sure. Hopefully after some benchmarks and watching how the traffic behaves on the different firmwares I can upgrade from wild guesswork to merely poorly-informed guesswork! :D
The lack of atomic guards...
OK, finally got the fix verified and it's posted on Github. This incorporates some other changes, including expanding the ENC28J60 receive buffer by 1536 bytes at the expense of the second transmit buffer: the TX impact appears to be quite minor, and RX performance improves significantly.
I'm...
The Daynaport has some pretty aggressive polling, so it may be able to empty the buffers faster than the Nuvo reconnect-then-send approach. I'll watch for that when I test your firmware here, which I'm planning on doing after this bug gets fixed.
This issue I'm working on is on the hard drive...
I think these weird speed differences are being caused by buffer spaces on the scuznet receiving side being shorter than what software is expecting. During FTP experiments, I keep seeing the same pattern of TCP retransmits for the last packet or two, and the sizes correlate to the buffer space...
We've been stickied, thanks mods!
Those are both exciting pieces of news about hardware, I'm looking forward to seeing what y'all have come up with.
No issues here: they're yours to do with as you please. I'm a spirited amateur with PCB design, so if you see areas where you'd suggest board...
Definitely can't fault you for giving it a go :D At least the last time I tried, I really didn't have luck doing the rough-layout for a board that incorporated those features. That's not saying it's impossible or anything: I wouldn't be shocked for a second if someone could make it work. It's...
Don't forget a solution for world peace, plus bonus RGB lighting. A man's gotta have some goals in mind! :)
More seriously, the only significant change I'd make for v2.1 would probably just be a better USB plug, that little micro USB one is a real trick to hand solder. That's not a big deal at...
Yup, that's the most current hardware revision. Be aware that at least the ENC28J60 appears to be widely out of stock currently, so you may have to be creative sourcing the proper chips.
Great, I'll try that out when I can get some time. That's a cool discovery about bunching packets into the...
100% agree. For me it's a minor battle to keep track of just one project some days :)
I'll do some experimenting with some other FTP daemons and see if I can find any differences. My suspicion is that this has more to do with Nuvolink/Daynaport stuff than it does with FTP; Wireshark should give...
Yeah, its weird that the performance difference is so pronounced. There are still a bunch of TCP retransmits happening on the wire during FTP activity: I thought from what I've read about TCP that it should self-correct as part of its congestion control, but maybe these buffers are so short that...
Learned something new today: the >MTU packets from vsftpd were just an artifact of Wireshark running on a host with "large send offload" active. In reality the network card was breaking up the packets before they hit the wire, so there was no MTU violation. Oops. For reference, this can be...
Cool, I'll give this version a try and see how things go.
I have an idea about why performance might vary so much after messing around more with vsftpd and Fetch. vsftpd seems to be sending frames in excess of the link MTU: at least in Wireshark, the "don't fragment" bit is set and there are...
I have been getting 2.5KB/s on both the SE and the IIci under 6.0.8 and 7.5.3/.5, running the Daynaport version 7.5.3 drivers. Wireshark showed nothing odd, apart from a 2 second delay between each 4-5KB AppleTalk data burst. Given that both of you weren't having any troubles like that I figured...
That's still excellent performance! I'm curious about the code changes, it's a far cry from the truly terrible throughput I'm getting on my Dayna tests; to be fair when both of you tested it you were getting much better results, so maybe I'm using a bad driver or something.
Good call, I forgot...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.