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

I should re-benchmark with Classic networking on my SE/30. I should have noted that I was running Classic networking on my SE when I was testing it earlier - OT requires an 030. (I was actually a bit surprised, booting the same 7.5.3 image which is normally Open Transport automatically switched to Classic networking when I booted it on my SE and magically reverted back to Open Transport when I went back to my SE/30).

That is really weird. This network is two computers: the IIsi and the Linux VM via a bridged adapter. There is basically no background traffic at all. At least on this hardware (my original V1 prototype), I was having unstable transmissions (lots of stalls / error flags set) until I redid things to be much more aggressive with re-transmitting. I have no idea why there's a difference. Maybe I have something else going on here, like sketchy hardware somewhere on the networking side.

I will say that things are vastly more stable on the transmission front after making those firmware changes, FWIW. The ENC28J60 is a buggy chip. If you want some nerdy entertainment, it's worth reading the errata sheet; a significant number of pretty important parts (full duplex, the pattern filter, etc) have severe enough flaws to make them basically unusable.

I doubt this is it, but could you take a look at the date stamp on the ENC28J60, to the right of the Microchip label? Mine starts with 1904 for reference.

I'm running on my regular network so there is definitely a lot of background activity. That being said, between the ENC settings, the pattern match filter and the filtering I do in the firmware, only wanted packets reach the Mac driver. My setup has no period appropriate hardware other than my client (ie. SE/30, SE or 145b) - The Synology (FTP Server) is a modern Linux-based NAS and Netatalk is a Linux-based AFP server. The Netatalk server is running on a VMware VM and connected to the LAN via a virtual adapter. So if there is an issue due to networking differences, moving to a vintage server solution will further increase those differences.

Interesting thought on the ENC chip. Mine is seems newer although I'm not fully sure how to interpret the date code - 20237EY. Maybe mine is a future-model - 2023 July where all the bugs were worked out??

Instead of using the master branch for a non-FATfs setup, would you mind checking the Version 2.0 hardware branch? What you're seeing on the master branch is interesting - When I put in the Mac address filtering (which is in the Version 2.0 hardware) I was starting to play around with trying to pre-cache some of the incoming packets. I'm not sure what happened exactly but at some point my system started to exhibit similar behavior where the Mac driver wouldn't see the inbound packets. The fix was to add a second delay after the MAC address gets transmitted which is what the current Multipacket branch does. I honestly don't know what exactly caused this to be required as I hadn't had any issues previously but I'm thinking that might be the issue you're seeing. The longer packets you're noting below might give the driver enough time to recovery without the extra post-MAC address delay.
I also did some research on the current 'master' branch Daynaport issues, which are... also weird. Fetch reliably crashes with a type 10 error. MacTCP ping will get one packet out right after a reboot, then will timeout on all subsequent packets. Each packet is being seen by Wireshark, and I've got the board's debugging interface reporting that replies are being sent to the host correctly - it's like the driver on the Mac is just rejecting the packet. Even more strangely, if I increase the packet payload size within MacTCP Ping it starts working fine! Packets larger than about 300-400 bytes are totally reliable. AppleTalk works fine. The Echo Test for Daynaport is completely fine too, even with small packets. Very strange.
 

saybur

Well-known member
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 remote host responding to 1), the Dayna driver assumes it is garbage and discards it.
  • Alternately, if scuznet lies and says there is no data available, the Dayna driver will issue another GET MESSAGE shortly afterwards. If scuznet responds to that with the packet, the driver works OK.
I'm guessing this is a consequence of all the changes to the transmission code. Both Fetch and Ping are now working under MacTCP. FTP downloads clocked in at 31.7KBs, uploads at ~90KB/s, so quite similar to performance under Nuvolink. AppleTalk performance is basically the same down, 41.5KB/s, and looks to be 15% slower at 31.2KB/s up (I didn't repeat this a ton, so it may just be noise). Neither of those numbers are very impressive compared to what you're getting, but at least the system works again.

I'm running on my regular network so there is definitely a lot of background activity. That being said, between the ENC settings, the pattern match filter and the filtering I do in the firmware, only wanted packets reach the Mac driver. My setup has no period appropriate hardware other than my client (ie. SE/30, SE or 145b) - The Synology (FTP Server) is a modern Linux-based NAS and Netatalk is a Linux-based AFP server. The Netatalk server is running on a VMware VM and connected to the LAN via a virtual adapter. So if there is an issue due to networking differences, moving to a vintage server solution will further increase those differences.

Agreed, sounds like my vintage server idea is the wrong direction. That setup sounds significantly more hostile than mine and probably makes for a much better testing environment.

Interesting thought on the ENC chip. Mine is seems newer although I'm not fully sure how to interpret the date code - 20237EY. Maybe mine is a future-model - 2023 July where all the bugs were worked out??

Haha, we can dream! I think we'll be extremely lucky if 2023 has any new chips in this series at the rate the silicon shortage is going. I'm guessing yours is week 23 of 2020, so not really that far removed from mine. At any rate, definitely new enough that the internal revision should be identical. It was a long shot as a trouble source, but thanks for checking anyway.

Instead of using the master branch for a non-FATfs setup, would you mind checking the Version 2.0 hardware branch? What you're seeing on the master branch is interesting - When I put in the Mac address filtering (which is in the Version 2.0 hardware) I was starting to play around with trying to pre-cache some of the incoming packets. I'm not sure what happened exactly but at some point my system started to exhibit similar behavior where the Mac driver wouldn't see the inbound packets. The fix was to add a second delay after the MAC address gets transmitted which is what the current Multipacket branch does. I honestly don't know what exactly caused this to be required as I hadn't had any issues previously but I'm thinking that might be the issue you're seeing. The longer packets you're noting below might give the driver enough time to recovery without the extra post-MAC address delay.

I saw that extra delay you added after the destination MAC was sent; during the investigation into my Dayna issues I tried to insert the same delay, but it did not have an observable impact on the IIsi. Per your comments it may still be needed for slower hosts: I'll need to try that out on my SE and see what happens.

I'll try out the other branch you indicated tomorrow and see what happens. I'm still really curious to see if the whole transmission stalling thing appears again. I had a good long walk and thought about it a while, but no epiphanies so far about why that's so much trouble here and not there.
 

Chopsticks

Well-known member
I should re-benchmark with Classic networking on my SE/30. I should have noted that I was running Classic networking on my SE when I was testing it earlier - OT requires an 030. (I was actually a bit surprised, booting the same 7.5.3 image which is normally Open Transport automatically switched to Classic networking when I booted it on my SE and magically reverted back to Open Transport when I went back to my SE/30).
I believe a bit is set in the pram to determine if OT should be enabled rather classic networking during the boot
 

Chopsticks

Well-known member
just finished up some testing with the latest firmware using daynaport emulation:

FTP maxes out around 93KB/s now, so that's a couple KB/s faster then last firmware
appleshare no longer hangs the system

doing a transfer from my main SE/30 with PDs network card over to my scuznet se/30 test rig I get an average of around 34KB/s transfer and it peaked at 37.4KB/s

doing a transfer from my 10.4.11 OS X Mac mini server to the scuznet se/30 I gout 57KB/s max transfer (I did leave the room after that so its possible it got a tiny bit faster)

doing a transfer from the scuznet se/30 to the Mac mini I got 140KB/s with an average of around 132KB/s

again ive had zero crashing/freezing issues is im pretty happy with that. also correct me if im wrong but im pretty sure these are the fastest/best results ive had with appleshare up to this point.

I also did another set of hdd benchmarks just to make sure nothing there was effected and I can report the performance at least with my sd card is a tiny bit faster then It was at 990KB/s and the butterfly test actually runs good now too, no longer taking a few minutes like it was when I tested out hdd performance several firmware revisions back
 

saybur

Well-known member
again ive had zero crashing/freezing issues is im pretty happy with that. also correct me if im wrong but im pretty sure these are the fastest/best results ive had with appleshare up to this point.

I also did another set of hdd benchmarks just to make sure nothing there was effected and I can report the performance at least with my sd card is a tiny bit faster then It was at 990KB/s and the butterfly test actually runs good now too, no longer taking a few minutes like it was when I tested out hdd performance several firmware revisions back

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 for posting those.

There's been a fair bit of discussion over the last couple pages; to help summarize for me, here are the items I still need to figure out (feel free to add):
  • There is a significant performance delta between the Daynaport work @superjer2000 has been doing and my implementation. The packet-stuffing technique he discovered needs to be added to my code, and I want to double-check versus his HWv2 branch and try to determine what's down to network/server differences and what is firmware related.
  • All those TCP retransmits are harming download performance. I'm going to do tests on Open Transport and see if it is better/same/worse.
  • It may be possible to squeeze out another 1.5KB buffer for a packet on the 64A3U, bringing the total RX buffer to 8K. This seems to be a "magic number" for buffer sizes from the Googling I've done and may help with the above issue.
 

superjer2000

Well-known member
So I pulled out my
I believe a bit is set in the pram to determine if OT should be enabled rather classic networking during the boot
That’s correct for a Mac that supports OT but Macs without enough RAM or without an 030 switch to Classic networking, even if OT is selected.
 
Last edited:

superjer2000

Well-known member
So I pulled my IIsi out and plugged in the Scuznet with my current Daynaport firmware and, completely surprising to me, I ran into problems: (Note that I booted off the Scuznet, so same System Folder that is working fine on my SE, SE/30 and PB 145B).

My IIsi only had 5MB of memory so I started off with Classic Networking as OT wouldn't load. Results:
* AppleShare upload kept stalling out and I ended up cancelling my transfer about 20% in instead of waiting
* AppleShare download OK versus SE/30 - 67kb/s.
* I couldn't get Fetch to connect (this might have been an issue with Classic networking - hard to say for sure)


I then upped the IIsi to 17MB of RAM and loaded OT:
* Slower AppleShare download: 57kb/s
* AppleShare upload still not really working - same issue as with Classic Networking
* Fetch connected OK and upload/download around 73 to 80kb/s

So there is something different happening on my IIsi (similar to what Saybur seems to have been experiencing) as compared to the other Macs I've tested with. So what's different?

1. IIsi is a different Mac. Maybe that model is cursed?
2. The IIsi is setup downstairs and so is connected to my network differently.
- I've been testing the other computers in my office which is connected to a managed gigabit switch through an unmanaged gigabit switch.
- Downstairs, the Scuznet is plugged into a 10 Base-T HUB (not a switch) which is then connected to my managed gigabit switch. I have the 10 Base-T hub at my "vintage Mac" desk as some older Mac network cards don't properly negotiate with 100 Base T and faster.
3. My IIsi has a Nubus Ethernet card installed - I find it odd that this would cause an issue though.

So three possible causes that I can think of. To try to narrow down the issue I will first plug the Scuznet into my wireless access point which is a gigabit switch. If that doesn't fix it, I'll pull the Ethernet card, and then if that still doesn't do it, I'll swap out the IIsi for a IIci.
 

superjer2000

Well-known member
So there is something different happening on my IIsi (similar to what Saybur seems to have been experiencing) as compared to the other Macs I've tested with. So what's different?

1. IIsi is a different Mac. Maybe that model is cursed?
2. The IIsi is setup downstairs and so is connected to my network differently.
- I've been testing the other computers in my office which is connected to a managed gigabit switch through an unmanaged gigabit switch.
- Downstairs, the Scuznet is plugged into a 10 Base-T HUB (not a switch) which is then connected to my managed gigabit switch. I have the 10 Base-T hub at my "vintage Mac" desk as some older Mac network cards don't properly negotiate with 100 Base T and faster.
3. My IIsi has a Nubus Ethernet card installed - I find it odd that this would cause an issue though.

So three possible causes that I can think of. To try to narrow down the issue I will first plug the Scuznet into my wireless access point which is a gigabit switch. If that doesn't fix it, I'll pull the Ethernet card, and then if that still doesn't do it, I'll swap out the IIsi for a IIci.

And the conclusions (all on my multipacket Daynaport firmware):
1) Either the Daynaport driver or the ENC doesn't like an old-fashioned 10 BASE-T hub. Plugging into my Wifi access point (gigabit switch) allowed the IIsi to work fine on AppleShare.
2) The IIsi itself kind of sucks. While connecting to a modern network switch allowed it to connect, it was still slower than an SE/30. Appleshare Down was 55kb/s and up was 45kb/s (with a bit of a pause part way through).
3) I then plugged the Scuznet into my other SE/30, keeping it connected to the gigabit switch. Appleshare down 71 kb/s up 66 kb/s
4) I then tried my IIci (8MB RAM, no L2 Cache, no video card, no Ethernet card. I was surprised it synced to my VGA monitor with an adapter. I thought I was going to have to pull out a CRT). Appleshare down 88 kb/s up 70 kb/s. I was surprised it was slower than my PB145b actually.
5) I then connected the Scuznet back to my hub (not my switch) and tried the IIci again. It hung up on an AppleShare up transfer so I cancelled the copy and shutdown.

To conclude:
1) Ethernet hubs = Bad. Ethernet switches = Good.
2) IIsi = Bad. All other Macs = Good
 

saybur

Well-known member
Either the Daynaport driver or the ENC doesn't like an old-fashioned 10 BASE-T hub. Plugging into my Wifi access point (gigabit switch) allowed the IIsi to work fine on AppleShare.

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 excellent for testing.

IIsi = Bad. All other Macs = Good

The joys of ancient hardware :D I will say, even through they're objectively not great Macs I have very fond memories of the IIsi. I bought one from my university's surplus store for 25 cents back when that was a thing: it had been languishing for weeks on a back shelf and I kind of felt bad for the little guy. Wish I still had that one. There was definitely was a reason nobody wanted it, it was slow as molasses even then, lol.

Thanks for doing such a deep dive into this. It certainly helps explain part of what was going on with my setup. My systems are connected via an old Netgear 10/100 switch, which I'm not confident is much of a switch at all. Might be worth plugging into some of the real networking equipment around here too.

I'm not sure if I've mentioned it before, but I do have a SE/30 in storage that I recapped about a year ago. Everything on it works fine except for the SCSI bus. I haven't been able to get it figured out, but it's high time that I work through that issue to get a comparable testing system.
 

aladds

Well-known member
Well I am now the proud owner of a working V2 board! A few false starts in places and a number of components which I thought I’d ordered but it turned out I didn’t (thankfully I was able to be creative with what I had on hand). This is running the latest version of the software from git.

So far I’ve tested this with an SE/30 running 7.5.5 with OpenTransport, and a PowerBook 100 running 7.0.1 with classic networking/MacTCP. On the SE/30 I’ve managed to get routing out to the internet working great as you can see in the picture.

I have managed to crash my PowerBook once with it, but I think my HDI30 adaptor is a bit wonky and I was moving things at the time.

My second set of boards are still in the post, so I won’t be making my PowerBook version just yet. I had a few ideas about cheap ways to make a WiFi module as discussed before, but I’m so far conceding that the Vonets module might be the best option. I’m still considering other options, though.

Not done any speed testing yet, that’s still to come 😊
 

Attachments

  • 781DE35B-0B47-421C-B3BA-C662C7077FB3.jpeg
    781DE35B-0B47-421C-B3BA-C662C7077FB3.jpeg
    3 MB · Views: 33
  • 436407D3-7A76-4009-BB2C-DF261C9310BE.jpeg
    436407D3-7A76-4009-BB2C-DF261C9310BE.jpeg
    1.2 MB · Views: 35

superjer2000

Well-known member
I had a chance to try the current firmware with the various fixes on Nuvolink emulation. On my SE/30 at least preliminary results seem to indicate pretty good stability. No crashes or other issues after transferring a 6mb file up and down via AppleShare and a 70mb file by ftp.

Performance is comparable to what I get on the Daynaport multi packet emulation (AppleShare down is the same up is a bit slower than Daynaport but that’s not a very common use case for me).

FTP is within spitting distance of Daynaport as well (maybe 5-7 kpbs slower).

Was there a smoking gun you found with regards to the previous instability on slower machines? Note that I haven’t tried it on my se. I’ll do that when I check cheesestraws updated force32 init.
 

aladds

Well-known member
Enough parts have arrived that I can install and do some minimum testing of the PB100 board. It needs a bit of work around the layout and placement of connectors, but aside from being just a tad wonky it’s pretty close to being neat.
Sadly the big header for my ribbon cable is too big and hits the bottom of the keyboard. Oops. I’ll have to solder the wires on directly at that end for V1 :)

I’m still waiting for a few parts for the “main” scuznet PB PCB - mostly the SCSI connector itself (being 2mm pitch, rather than 2.54, it’s not something I have to hand!)

That’ll probably need mounting holes and things in the future too. Although a 3D printed surround might be better. Lots of things to try :)
 

Attachments

  • A1C38CB5-9098-41CC-9CB5-A2825A2AAA05.jpeg
    A1C38CB5-9098-41CC-9CB5-A2825A2AAA05.jpeg
    2.8 MB · Views: 30
  • A6338667-E14C-43C7-ADE9-F64A4EA01679.jpeg
    A6338667-E14C-43C7-ADE9-F64A4EA01679.jpeg
    779.8 KB · Views: 41
  • 7BCE8F1A-F86D-4F04-BF30-5FB9D2478B76.jpeg
    7BCE8F1A-F86D-4F04-BF30-5FB9D2478B76.jpeg
    2.2 MB · Views: 23
  • 47EEA3EC-1FC2-4693-BC5C-574A3B0C93A7.jpeg
    47EEA3EC-1FC2-4693-BC5C-574A3B0C93A7.jpeg
    1.2 MB · Views: 29

saybur

Well-known member
Was there a smoking gun you found with regards to the previous instability on slower machines?

The big one was correctly respecting the DISCONNECT message sent from the Mac during certain phases and extending the disconnection delay to several milliseconds. Improving the transmission error handling also helped, along with better handling of DMA underflow conditions (thought that last problem was a later addition).

It's good to hear that Nuvolink performance is more comparable (and stable) now. I'm currently working on some more changes to network reception to extend the buffers, which is proving to be really tricky with the 64A3U. Like, to the point where clawing back a dozen bytes of SRAM is making the difference between success and failure. We'll see how that works once I get the code modified.

Enough parts have arrived that I can install and do some minimum testing of the PB100 board.

That's a pretty slick way to get Ethernet out. Looks nice! :)
 

aladds

Well-known member
As promised I'm trying new things.

I can't get my (normal) scuznet card to appear with my 450Mhz G4 Yikes. I have an Adaptec 2906 PCI SCSI card installed

Not sure if I can get much more information about this for you, but if I look in the PowerDomain control panel (which recognises the card) it doesn't see the ScuzNet adaptor at all.

I will note that with version 1.2 of the 2906 SCSI driver I got a bus error on startup. With version 1.3 (which, curiously, I managed to download from the Microchip website!) it boots, but still doesn't appear.

I enabled debugging and hooked it up to Sigrok with a stacked UART decoder at 500kbps (as I vaguely remember reading somewhere, it seems to decode so I think I got it right). I've attached that file - this file contains a whole boot, then I open the PowerDomain control and press "rescan" a couple of times (I think there are three bursts of data corresponding to the three scans).

Edit: and to confirm it wasn't somehow broken, I then checked it on the SE/30 and it still works fine.

Let me know if I can try anything else! :)
 

Attachments

  • Adaptec-boot-threescans.txt
    21 KB · Views: 5
Last edited:

saybur

Well-known member
The Sigrok gave great output, thanks for that. It's failing after starting an INQUIRY command. The 0x5F is the LOGIC_MESSAGE symbol (from debug.h), issued after nonstandard message receipt. In this case it's 0x05, the SCSI message "INITIATOR DETECTED ERROR". That's a pretty generic error, so hard to say for sure what's up; I haven't tested a scuznet on a modern system for a while, so it's possible something is incorrect in the firmware.

One thing to check: do you have 'parity=yes' in the config file? With the newer 2606 I wouldn't be surprised if it was expecting it.
 

aladds

Well-known member
Right you are! Parity=yes has made it work...although it does seem a little unstable (could be the G4, but I don't *think* so)

Here's another log from sigrok. Note that the HD didn't automount - I had to use SCSIProbe. I've not tested the Ethernet adaptor yet but I'd be surprised if it works on 9.2.2!
 

Attachments

  • Adaptec-parityOn.txt
    30.2 KB · Views: 1

saybur

Well-known member
Oh yeah, I seriously doubt the Ethernet drivers will work on modern OSes. It definitely doesn't work right in Basilisk II either, which is too bad, it would have made an easier development platform. The hard drive emulation should be fine and I do want it to work right, since that's a decent use case for setting up volumes and stuff.

There's no help in the debugging output this time unfortunately: the 0x80/81 pair are normal "read starting/stopping" symbols. Ditto with 0x82/83 for writing. The lack of mounting on startup might be something weird with the INQUIRY response, but it's hard to tell for sure there.

What kind of instability are you experiencing? If its hard-locking, are you getting the status LED lit solid on, or is it dark?
 

aladds

Well-known member
Doing a bit more testing without the card plugged in I’m tempted to say that a lot of this is down to my OS 9 install (I use it for playing with new things all the time!)
So I reverted to the base 9.2.2 extensions set (plus the SCSI card driver) and tried again.

It was much more reliable this time. Still doesn’t mount automatically (I set SCSIProbe to mount all drives during boot in the end, that sorted it!) but otherwise seems good.

So i started running some tests.

Disk First aid was happy with the drive as a first test. I was able to copy files on and off it just fine.
I did a BenchTest with FWB HDT 4.5.2 - I made PDFs of the results and they’re attached. Interestingly it doesn’t seem to have much of a performance penalty to have debugging on.
 

Attachments

  • Scuznet HD debug off.pdf
    3.3 KB · Views: 3
  • Scuznet HD debug on.pdf
    3.3 KB · Views: 1
Top