Search results

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...

Just caught a nasty bug I introduced in the 'forcefast' code. Fixed on Github; you likely want to re-pull. I'm not on my A game tonight :P

Ooh, that is great news! Hopefully the net.c cleanup is making your life easier, but if you have suggestions for changes there I'm all ears. On the hard drive side, I've pushed fixes for several bugs but I haven't gotten the underlying boot issue Chopsticks experienced figured out completely...

Good news (sort of): I tried a different SD card, starting from scratch with a 'size=2048' file in fast mode, and I think I've been able to replicate this issue. I'll dig into it and figure out what's going on. That's a good hint, and probably points to a SCSI transfer getting stuck. That's...

Thanks for trying it out so fast! I'll dig into the network lockups tonight and see if I can replicate them on my hardware. The issue with 'fast' is weird, I haven't had anything like that here. Is the sluggish performance happening with 'forcefast' too?

All three are still supported, like so: "normal" accesses through the FAT filesystem only. Highest compatibility, but slow with larger cluster sizes (particularly on FAT32). "fast" is low-level access bypassing the FAT filesystem, but only after the continuity check clears: before that it acts...