• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

SCSI to Ethernet Adapter on New Hardware

superjer2000

Well-known member
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..
That is odd. I’m not sure what truly terrible means but you should expect at least 75kbs on your IIci using the original Daynaport firmware I had added. I did notice that something seems to get installed that hampers performance if you do a full install of system software for any Mac (including PowerPC) but you should still get say 50kbs on a IIci in that case. I just do the install for my se/30 of 7.5.3 and that seems to boot up everything I care about anyways. I’m also running OT1.3 but that doesn’t seem to have much of an impact.

I do pull the Nuvolink driver from the DRVR resource in the system file though before installing Daynaport as the two don’t seem to play nice. (Delete all of the .enet references)
 

saybur

Well-known member
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 it must be something weird in my setup over here.

On the Nuvolink side, in what's become depressingly common I've been unable to replicate the network freezing issue. I've been swapping a 70MB file back and forth between my IIci and a Basilisk II host, and have been reliably getting excellent transfer speeds and no glitches.

I also installed vsftpd on my system and have had poor luck getting Fetch to transfer files correctly. Somewhere along the lines the MTU is being being mis-configured and Wireshark shows vsftpd sending packets ~3KB in size. For @Chopsticks, what FTP server software are you using? I'd like to replicate the setup over here to reduce the number of variables.
 

superjer2000

Well-known member
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 it must be something weird in my setup over here.
My installer seems to be 7.7.2. The Scsilink software that gets installed is 1.2.5 (when the installer is opened)
 

Chopsticks

Well-known member
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 it must be something weird in my setup over here.

On the Nuvolink side, in what's become depressingly common I've been unable to replicate the network freezing issue. I've been swapping a 70MB file back and forth between my IIci and a Basilisk II host, and have been reliably getting excellent transfer speeds and no glitches.

I also installed vsftpd on my system and have had poor luck getting Fetch to transfer files correctly. Somewhere along the lines the MTU is being being mis-configured and Wireshark shows vsftpd sending packets ~3KB in size. For @Chopsticks, what FTP server software are you using? I'd like to replicate the setup over here to reduce the number of variables.
well my main server is running macOS Big Sur, and ive tried a few ftp server over the course of testing the scuznet but for at the last few months ive been using a commercial program called Rumpus, its not free but its obtainable.
until I installed rumpus I was getting poor ftp transfer results in my testing. I have no idea why but since migrating top rumpus I get similar result to superjet2000 (not exactly the same but similar or at least in the same ballpark as he gets)

ive actually setup a second SE/30 just for the scuznet testing as I get worse results when I use my main SE/30, though I suspect that is due to the color video PDS card having some negative effect on performance of the Mac as well as the fact that I have a couple external scsi devices in the chain (Zip drive, CDRW drive) and an internal V1 scuznet with much older firmware compiled without the ethernet support). I figured that for best testing that I would run a stock SE/30 with 32mb ram, a 32bit clean rom (exact same rom image as my main machine) and having literally no other scsi devices in the chain besides the logic board and the scuznet.

I not sure why there is issues with the SE/30 and the nuvolink emulation. I have a Iici logic board and it runs fine on that fwiw
 

aladds

Well-known member
Before "the event" I was talking about getting some PCBs made for this - I think it was over on the thread in FS/FT since I was hoping to buy one at that point.

Anyhow, I'm now waiting in delivery of parts so I can put them together (and I'm likely to have a few spares, either plain PCBs or if I can get enough ATXMEGA chips, possibly complete boards). At that point I'm happy to help debug too. I have an SE/30, a couple of 68k powerbooks and a G4 Yikes with SCSI to hand which I can use for testing.

Which brings me to something else; it's been a while since I've done much PCB design, and I'd not used KiCad before, but for an exercise in learning and something to do, I've been making a new version of the board which fits inside a 2.5" SCSI HD bay, with some headers instead of Ethernet/LED connectors, with the aim of making a card which can go in my PB100 and replace the Modem blanking plate with RJ45 Ethernet - I may even consider doing a version using an ESP8266 in "device mode" instead of the ENC28J60, but that's something else entirely. Anyway I'm likely to send off my PCB design to be made in a week or so (pending how busy I am in the day job!) so at that point I'll share my modifications at the very least. :)
 

saybur

Well-known member
My installer seems to be 7.7.2. The Scsilink software that gets installed is 1.2.5 (when the installer is opened)

Cool, I'll give this version a try and see how things go.

until I installed rumpus I was getting poor ftp transfer results in my testing. I have no idea why but since migrating top rumpus I get similar result to superjet2000 (not exactly the same but similar or at least in the same ballpark as he gets)

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 many packets of 2974 bytes (and many TCP retransmits). What's weird is that there are TCP ACK packets from the Nuvolink in reply to these jumbo frames. This needs more investigation.

On the plus side, I found a source of system lockups while using Fetch. It appears that the spec-based 200 microsecond delay following a DISCONNECT message appears to be way too short. These messages aren't common on AppleTalk, but the longer IP packets during FTP transfers seem to have increased their frequency. The disconnection delay has been bumped up to 5000 microseconds. This could be why the SE/30 freezes and the IIci doesn't: the faster CPU/SCSI on the IIci could be more tolerant of the device reconnecting too soon.

If you want to try what's up on Github now, let me know how it goes.

ive actually setup a second SE/30 just for the scuznet testing as I get worse results when I use my main SE/30, though I suspect that is due to the color video PDS card having some negative effect on performance of the Mac as well as the fact that I have a couple external scsi devices in the chain (Zip drive, CDRW drive) and an internal V1 scuznet with much older firmware compiled without the ethernet support). I figured that for best testing that I would run a stock SE/30 with 32mb ram, a 32bit clean rom (exact same rom image as my main machine) and having literally no other scsi devices in the chain besides the logic board and the scuznet.

Man, if it can be made stable and fast there it should hopefully be good everywhere. That is a really nice SE/30 :)

Anyhow, I'm now waiting in delivery of parts so I can put them together (and I'm likely to have a few spares, either plain PCBs or if I can get enough ATXMEGA chips, possibly complete boards). At that point I'm happy to help debug too. I have an SE/30, a couple of 68k powerbooks and a G4 Yikes with SCSI to hand which I can use for testing.

That sounds great! Let us know how the assembly goes. If there's parts that are difficult, it'd like to add assistance to the wiki to help others out down the line too.

Which brings me to something else; it's been a while since I've done much PCB design, and I'd not used KiCad before, but for an exercise in learning and something to do, I've been making a new version of the board which fits inside a 2.5" SCSI HD bay, with some headers instead of Ethernet/LED connectors, with the aim of making a card which can go in my PB100 and replace the Modem blanking plate with RJ45 Ethernet - I may even consider doing a version using an ESP8266 in "device mode" instead of the ENC28J60, but that's something else entirely. Anyway I'm likely to send off my PCB design to be made in a week or so (pending how busy I am in the day job!) so at that point I'll share my modifications at the very least. :)

I have a feeling @superjer2000 is going to be happy to hear this :D There was some discussion a few pages back, probably in the lost posts, about doing that kind of board revision so there's definitely interest around here. Swapping the ENC28J60 out would require some code surgery, but the hardware remix should mainly be a new 'hw_XX.h" file.
 

saybur

Well-known member
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 disabled under Linux via `ethtool --offload ethX tso off`

I also experimented wtih removing one of the two Ethernet transmit buffers and re-allocating that space to the receive buffer. When I did that, Fetch performance with the Nuvo emulation on my IIci increased from ~20KB/s to ~33KB/s while downloading. For comparison, originally there was 5K allocated on the ENC28J60 for RX, whereas that is 6.5K with just 1 TX buffer. That's probably as far as the buffers can be stretched, unless some DMA trickery can be used to move data into the AVR faster. That'll have to be a project for a different day. As of now, this TX buffer change was reverted in Github in case it broke something else, but it is in the history if anyone wants to tinker with it.
 

superjer2000

Well-known member
I also experimented wtih removing one of the two Ethernet transmit buffers and re-allocating that space to the receive buffer. When I did that, Fetch performance with the Nuvo emulation on my IIci increased from ~20KB/s to ~33KB/s while downloading. For comparison, originally there was 5K allocated on the ENC28J60 for RX, whereas that is 6.5K with just 1 TX buffer. That's probably as far as the buffers can be stretched, unless some DMA trickery can be used to move data into the AVR faster. That'll have to be a project for a different day. As of now, this TX buffer change was reverted in Github in case it broke something else, but it is in the history if anyone wants to tinker with it.
You are getting 100k+ on Appletalk but only 30k on FTP? That is really weird.
From the work I have done, FTP has almost always been faster - I assumed due to less overhead for tcp than appletalk. Are you running OpenTransport? While I am getting about 76kbs on appletalk on my SE30 now I am still getting closer to 85 on fetch.

My FTP server is just a standard non encrypted FTP running on a Debian vm alongside my netatalk server.
 

saybur

Well-known member
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 its hitting the limits of what it has been programmed to do. Definitely not quite right.

AppleTalk (AFP?) data bursts seem to always be ~5K in response to a data request, which fits in the buffer without issue. I don't see any retransmits happening there.

Out of curiousity, which FTP daemon are you running? I'm running vsftpd without inetd. I was wondering if it might be "tuned" for higher performance machines than ftpd or pure-ftpd, but I haven't tinkered with those yet.
 

superjer2000

Well-known member
Out of curiousity, which FTP daemon are you running? I'm running vsftpd without inetd. I was wondering if it might be "tuned" for higher performance machines than ftpd or pure-ftpd, but I haven't tinkered with those yet.

Rewind my prior comment on me running FTP on Debian. It's amazing how all of these various projects start to blend into one big blob in my mind after a while. That was my prior setup when I had my netatalk server running on a raspberry pi. IIRC, the default FTP daemon with Debian only supported encrypted FTP which wasn't going to work but I can't recall what I installed instead. I just did a quick google search and I think it might have been pure-ftpd?

Either way, fast forward to my current setup: VM running Debian and the latest version of Netatalk which points to a share on my Synology NAS. My FTP server now is actually my Synology NAS pointing to the same share. So my FTP server is just my Synology which has worked great, out of the box, with Fetch. I did a quick search to see what ftp daemon the Synology might be running but can't up empty handed.
 

superjer2000

Well-known member
One other point for project documentation -

As noted I've been working to optimize the Daynaport emulation and have been able to make some pretty significant improvements on AppleTalk performance.

* I had made my original changes on the scuznet.ini version of the base firmware (the version that supports forcefast).
* As I'm still running a poor-cousin Scuznet with a 64A3U (no exFAT support, just FAT32 with the "forecefast" RAW=style mode, I thought I'd try to backport my changes to the earlier version of the firmware that supported the V02 board but pre-fatFS to see if that might even be a bit faster.

To my surprise, no. Performance is pretty much the same with AppleTalk (and perhaps a bit slower actually - ATalk 71kB/s on pre-fatFS and 76kB/S on fatFS Scuznet. FTP seems to be a bit slower, topping out at 89kB/s on pre-fatFS and eventually getting to 100kB/s on fatFS.

Ultimately this means I'll just stick with the fatFS version and post the updated Daynaport code this weekend.

For system comparison purposes, I just did a new System Software install on a ScuzNet volume as follows:

* Installed 7.5.3 for THIS MACINTOSH (my SE/30) (Custom install - I also selected Open Transport in networking options).
* Installed the version of Daynaport drivers I referenced above - Again, custom install to just install the driver, not the AppleTalk extension the driver ships with as the OT version is newer (I did the same thing with the nuvolink)
* I updated to OT1.3. This time I also did a custom install to just install OT for 68k macintoshes. Note that going from the default OT in 7.5.3 (I think it's 1.1.2?) to 1.3 didn't really make a difference in speed.

QUESTION: Any thoughts as to whether I'd see an increase in speed going to a higher RAM ATXmega to run exFAT, or is the FAT32 / forcefast around the same speed?
 

saybur

Well-known member
It's amazing how all of these various projects start to blend into one big blob in my mind after a while.

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 some hints on that front.

As noted I've been working to optimize the Daynaport emulation and have been able to make some pretty significant improvements on AppleTalk performance.

* I had made my original changes on the scuznet.ini version of the base firmware (the version that supports forcefast).
* As I'm still running a poor-cousin Scuznet with a 64A3U (no exFAT support, just FAT32 with the "forecefast" RAW=style mode, I thought I'd try to backport my changes to the earlier version of the firmware that supported the V02 board but pre-fatFS to see if that might even be a bit faster.

To my surprise, no. Performance is pretty much the same with AppleTalk (and perhaps a bit slower actually - ATalk 71kB/s on pre-fatFS and 76kB/S on fatFS Scuznet. FTP seems to be a bit slower, topping out at 89kB/s on pre-fatFS and eventually getting to 100kB/s on fatFS.

When using 'forcefast' FatFs is just used to get the file size and starting LBA: after that FatFs is ignored and all read/write calls route directly into disk.c. Those routines use DMA ping-pong buffering instead of the direct USART/SCSI byte swapping in the old firmware, which should be slightly more efficient. That seems to be borne out in your testing (thanks for doing that, it had been a while since I tried any A/B comparisons there). There is still room for improvement: the old SCSI _offer_block() routine was a hand-tuned, unrolled loop of AVR assembly to maximize performance. I got rid of that during the changeover, but figured it would make a return once the hard drive re-coding settled down.

To more directly answer your question, as long as you're using 'forcefast' you should see no difference between FAT32 and exFAT performance. When using 'fast' the only performance penalty will be during the first ~15-30 seconds after board reset (depending on the volume sizes) as the contiguous check runs. If that clears successfully, a 'fast' volume will then be just as performant as 'forcefast'.

The only caveat for 64A3U vs. bigger chips I see coming is on the network side. I was surprised at the ~50% performance increase I mentioned yesterday on my IIci after adding just 1.5K of extra buffering. I've been pondering whether to add some kind of extra DMA data reading for Ethernet packets to try and move them off the ENC28J60 faster, which is pretty much the only way left to get more buffer space. To do that "right" would probably involve more ping-pong buffers, but that's a whopping 3K of SRAM and would even squeeze the 128A3U. No guarantees on this approach, but just be aware of that thought.

Ultimately this means I'll just stick with the fatFS version and post the updated Daynaport code this weekend.

Excellent, I'd love to take a look. It'll give me a good excuse to start working with the new Daynaport Mac drivers, I still haven't tried those out yet.
 

superjer2000

Well-known member
I added a new branch for the Daynaport emulation at https://github.com/superjer2000/scuznet/tree/Daynaport---Multipacket

If anybody else can test, I'd appreciate it. As noted previously, I am getting about 75k/s on my SE/30 and about 100k/s on my PB145b with AppleShare, and about the same with FTP via Fetch. (On my PB145 it gets to 85k/s pretty fast on Fetch an then takes a while to get to the 100k mark.)

Note that this is a scuznet.ini fork.

Per the below a reasonably clean install and the latest daynaport drivers might be worthwhile to maximize speed.

* Installed 7.5.3 for THIS MACINTOSH (my SE/30 which also worked for my pb145b) (Custom install - I also selected Open Transport in networking options).
* Installed the newest version of Daynaport drivers (My installer version is 7.7.2. The Scsilink software that gets installed is 1.2.5 (when the installer is opened)))- Again, custom install to just install the driver, not the AppleTalk extension the driver ships with as the OT version is newer.
* I updated to OT1.3. This time I also did a custom install to just install OT for 68k macintoshes. Note that going from the default OT in 7.5.3 (I think it's 1.1.2?) to 1.3 didn't really make a difference in speed.
 
Last edited:

superjer2000

Well-known member
I added a new branch for the Daynaport emulation at https://github.com/superjer2000/scuznet/tree/Daynaport---Multipacket

If anybody else can test, I'd appreciate it. As noted previously, I am getting about 75k/s on my SE/30 and about 100k/s on my PB145b with AppleShare, and about the same with FTP via Fetch. (On my PB145 it gets to 85k/s pretty fast on Fetch an then takes a while to get to the 100k mark.)

Note that this is a scuznet.ini fork.

Per the below a reasonably clean install and the latest daynaport drivers might be worthwhile to maximize speed.

* Installed 7.5.3 for THIS MACINTOSH (my SE/30 which also worked for my pb145b) (Custom install - I also selected Open Transport in networking options).
* Installed the newest version of Daynaport drivers (My installer version is 7.7.2. The Scsilink software that gets installed is 1.2.5 (when the installer is opened)))- Again, custom install to just install the driver, not the AppleTalk extension the driver ships with as the OT version is newer.
* I updated to OT1.3. This time I also did a custom install to just install OT for 68k macintoshes. Note that going from the default OT in 7.5.3 (I think it's 1.1.2?) to 1.3 didn't really make a difference in speed.
For some additional upside, the hang I was getting at shutdown when just running a TCP app without an AppleShare volume mounted seems to be gone as well.
 

superjer2000

Well-known member
Before "the event" I was talking about getting some PCBs made for this - I think it was over on the thread in FS/FT since I was hoping to buy one at that point.

Anyhow, I'm now waiting in delivery of parts so I can put them together (and I'm likely to have a few spares, either plain PCBs or if I can get enough ATXMEGA chips, possibly complete boards). At that point I'm happy to help debug too. I have an SE/30, a couple of 68k powerbooks and a G4 Yikes with SCSI to hand which I can use for testing.

Which brings me to something else; it's been a while since I've done much PCB design, and I'd not used KiCad before, but for an exercise in learning and something to do, I've been making a new version of the board which fits inside a 2.5" SCSI HD bay, with some headers instead of Ethernet/LED connectors, with the aim of making a card which can go in my PB100 and replace the Modem blanking plate with RJ45 Ethernet - I may even consider doing a version using an ESP8266 in "device mode" instead of the ENC28J60, but that's something else entirely. Anyway I'm likely to send off my PCB design to be made in a week or so (pending how busy I am in the day job!) so at that point I'll share my modifications at the very least. :)

I haven't really used KiCad either (other than for following Scuznet schematics when troubleshooting). If I had more time, I would press ahead with exactly what you're proposing (similar to what I had proposed before "the event" - a Scuznet with a 2.5" HD footprint and ideally a header that would interface into a powerbook's scsi connector (44 pin?)

I had explored doing using an ESP module or something similar and concluded that the only way to bridge Scuznet to Wifi (unless somebody wanted to write a 68k Wifi driver) is to use a mini-router (something that can run OpenWRT for example.) All of the other devices just support a serial to WIFI TCP option and you need something that can route 802.3 packets over 802.11.

I settled on the same module that that Ants used to to add wifi to his SE/30 (vonnet VM300) and it works great - you can see my Wifi scuznet below. All it needs is power and a scsi cable and I can use my Powerbook at the kitchen table. Performance isn't really any different than a wired scuznet.

A few other notes:
1) The only way I could think of to interface the Vonnet module was to remove the Ethernet jack on the Scuznet and use an ethernet transformer to bridge the connections between the Scuznet and the Vonnet.
2) Ideally, a Powerbook Wifi Scuznet would delete the Ethernet jack and instead have a place to mount an SMD
Ethernet Transformer chip with the output going to a set of header pins that could then be jumpered to the VM300 or similar module.
3) This would also allow for different options for an internal compact Mac Scuznet as a magnetic-less Ethernet jack could still be used remote from the Scuznet.
Wifi1.JPGWifi2.JPGWifi3.JPGWifi4.JPG
 

saybur

Well-known member
I would like to build a board for myself just to test it out. What's the recommended way to do this ? Is the board at https://github.com/saybur/scuznet/tree/master/hardware the correct version ?

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 one transfer. Nicely done! :)

Not a lot of time to devote to the project this week, and what I've got has been spent chasing my tail with some really strange hard drive lockups. I suspect it is related to a new batch of memory cards I've been working with. Hopefully can get that figured out: it's been quite maddening.
 

aladds

Well-known member
My boards arrived today! Sadly a lot of other parts are still in the post, including the AVR/Ethernet controller chips, so I’m still a bit of a way off actually testing anything. F4193E34-C82D-423B-B880-81D7A0320C3A.jpeg
 
Top