@Leo

Quote:

WDM drivers didn't work on Windows 3.1.

No, but they were designed to run on all Windows operating systems supported by Microsoft at the time, including Windows 98.

I think the MorphOS and AROS developers are more than capable of adapting any new specification on their own. (And the risk of Roadshow details bleeding into a new specification may get legally tricky for Olaf.)

Also note that supporting fancy "new" features like scatter/gather I/O and checksum offloading might require subtle changes in the IP stack. Those changes wouldn't be portable; however, we could work around that, e.g. using a standard method of managing buffers and querying the device for checksum offloading. Some features can be enabled and disabled on the fly, though, and there must also be a way of notifying the IP stack of the change.

Fortunately, we have lots of patent-free source material from which to pull ideas.

Last edited by Trev on 24-Sep-2010 at 07:55 PM.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

Quote:

No, but they were designed to run on all Windows operating systems supported by Microsoft at the time, including Windows 98

Indeed. But at that time Windows 98 was 3-4 years old, certainly not 18-19 years old...

_________________
http://www.warpdesign.fr/

@Leo

Yes, however WDM is still supported by Windows Server 2003, which is very, very widely deployed. That puts it at around the 12 year mark in terms of actual production use. Its replacement, KMDF, can be used on Windows 2000.

Our current driver model is much, much, MUCH more basic than either WDM or KMDF. It wouldn't be difficult to add new features to SANA-II and deprecate old ones. The most difficult part of the process would be adapting layer 3 software and layer 2 drivers to use the new features--especially the features that blur the lines between those layers. There are only a few active network system developers on AmigaOS, after all.

Last edited by Trev on 24-Sep-2010 at 10:42 PM.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev

Does anyone know how MNI works? Drivers exist for most old hardware and it seems to take care of the issues everyone has with SANA-II.

It seems that what is being said that if a new standard is created, new hardware might support it but no one will port the old hardware to the new spec thus no support.

In Miami deluxe a new driver interface was created called MNI. The author of Miami wrote all new drivers for most zorro cards. If MNI was documented, then MNI could be used and support for old hardware could be used with MNI drivers without using Miami.

Here is a mail list post about MNI. The author even wanted it to be a future standard.

MNI Mailing List Link

Kinda of a long shot but just an idea.

_________________
A500/030 40mhz with A530, Indivision ECS, , KS 3.1, 2 Megs Chip, 8 Megs fast.
A600 Vampire II Black Edition, SumA600 USB KB Adapter
SAM440EP 667, Amiga OS 4.1u1
Dual G4 1.2 Mac MorphOS
Chameleon
CD32
SX64
128D
128

@omnicron10

Quote:

Does anyone know how MNI works?

I suspect Olaf does, and I also suspect there are reasons why it wasn't used in Roadshow.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

Quote:

I suspect Olaf does, and I also suspect there are reasons why it wasn't used in Roadshow.

And I would be interested to know these reasons :)

_________________
http://www.warpdesign.fr/

@Trev

Quote:

Trev wrote: @omnicron10 Quote: Does anyone know how MNI works? I suspect Olaf does, and I also suspect there are reasons why it wasn't used in Roadshow.

No, I do not know how MNI works. I was too late for the party, so to speak. By the time I became curious about how a TCP/IP stack might be ported to the Amiga, Holger had already dropped out of the picture.

There was no conscious decision to avoid MNI for use within Roadshow. It just never entered the picture. There never was any publicly available MNI documentation or reference driver implementation source code. SANA-II documentation and source code, flawed and incomplete as is was, was readily available, and there were plenty of hardware drivers the TCP/IP stack could use. MNI never had more than three, if I remember correctly, all written by Holger.

Holger's mailing list posting on MNI is right on the money, in every paragraph, in which he picks apart what SANA-II doesn't do right, or doesn't even address. It's ironic that some of the best points of criticism he made about SANA-II eventually came to apply to MNI.

@omnicron10

Quote:

omnicron10 wrote: @Trev Does anyone know how MNI works? Drivers exist for most old hardware and it seems to take care of the issues everyone has with SANA-II. It seems that what is being said that if a new standard is created, new hardware might support it but no one will port the old hardware to the new spec thus no support. In Miami deluxe a new driver interface was created called MNI. The author of Miami wrote all new drivers for most zorro cards. If MNI was documented, then MNI could be used and support for old hardware could be used with MNI drivers without using Miami. Here is a mail list post about MNI. The author even wanted it to be a future standard. MNI Mailing List Link Kinda of a long shot but just an idea.

Now this is just speculation, since I haven't got any idea how MNI works, but the points Holger made in this posting all ring so true that it would be hard to avoid using the ideas he hints at.

For example, according to this posting MNI drivers are implemented as shared libraries, rather than plain Exec device drivers. This is just the track I thought a future SANA-II standard could be taking. For DMA to be supported, memory management has to move out of the TCP/IP stack and into the drivers. And that's hard to do just with device I/O operations. A set of function calls would be a more fitting solution for that.

Quote:

Yes, however WDM is still supported by Windows Server 2003, which is very, very widely deployed. That puts it at around the 12 year mark in terms of actual production use. Its replacement, KMDF, can be used on Windows 2000.

Difference is that Microsoft has millions of legacy customers to support. Customers that need these drivers... Amiga has barely anyone to support: that's a wonderful opportunity to start something from scratch

I don't think most pre 3.1 users give a penny about a new driver architecture... Sure, there are a lot more classic users than modern AmigaOS (I include OS4, MorphOS and AROS in this list), but these users probably don't care about that and mostly use their computer for retro stuff.

_________________
http://www.warpdesign.fr/

@Leo

Quote:

I don't think most pre 3.1 users give a penny about a new driver architecture.

The whole point of this thread is the discussion of Roadshow on classic Amigas. Roadshow's performance on 680x0 appears impressive as it is. A new driver specification would improve performance, but I don't think anyone's going to write new drivers for all the legacy hardware out there. At the very least, we would need a SANA-II wrapper. So, backward compatibility of some sort is important, regardless of how and where it's implemented.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@olsen

Quote:

For DMA to be supported, memory management has to move out of the TCP/IP stack and into the drivers.

Does it? On AmigaOS 4.x, for example, couldn't a device export a DMA flag of some sort which the IP stack uses as a switch between something like AllocVec and the Exec DMA functions? The same functions could be back-ported to AmigaOS 3.x, or DMA could be handled in a different way.

I have a knowledge gap here. I don't see how IExec->StartDMA would support a situation where the stack has TCP headers at one virtual address, user data at another, and wants to pass them to the driver as a list which is then combined with MAC headers and passed to the hardware using a DMA scatter/gather list.

How do we handle 32-bit devices that need physical addresses below the 4 GB boundary? Do we have software support for DAC on hardware that supports it? (Neither of those should be an issue at the moment, but as with 24-bit DMA, 32-bit DMA will necessarily be a special case in a 64-bit environment.)

Receiving data doesn't sound too complicated, although small optimizations like padding the buffer to properly align the data portion of the packet, either on an appropriate word, page, or cache boundary, would have to be performed by hand.

Standardized support for polling would be good, too. Interrupt processing overhead on a 10 GbE PCIe device, for example, would quickly saturate the system. It could happen with other high performance devices as well.

We might also want to consider a way to pause the stack's transmit queue when an interface is saturated.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev

Quote:

Trev wrote: @olsen Quote: For DMA to be supported, memory management has to move out of the TCP/IP stack and into the drivers. Does it? On AmigaOS 4.x, for example, couldn't a device export a DMA flag of some sort which the IP stack uses as a switch between something like AllocVec and the Exec DMA functions? The same functions could be back-ported to AmigaOS 3.x, or DMA could be handled in a different way.

The "modern" NICs (I think 3com invented and patented the approach in the mid 1990'ies for their fast Ethernet chips) use data structures very, very similar to the BSD TCP/IP stack's internal memory management data structures. The basic element is a cluster (a page-sized chunk of memory allocated on a page boundary), which is broken down into fragments of 128 bytes each, or larger. Preferably larger, e.g. each inbound/outbound packet has to fit into an mbuf. For TCP fragments the mbufs can be smaller.

The NICs I know of prefer it if their internal data structures are linked together. Each link of the chain is large enough for a packet to fit, and the chain usually forms a circle. Each element contains additional information, indicating whether or not the element contains data, if the checksum is OK, how large the packet stored is, etc.

The problem to be solved by moving the memory management, or rather the packet memory management, is that we need a hardware abstraction layer. Not all NICs share the same preferences for data structure layout in memory. I think it would be the best approach to perform this abstraction within the driver itself rather than forcing the client software to figure out how exactly the driver hardware wants to play the game

Quote:

I have a knowledge gap here. I don't see how IExec->StartDMA would support a situation where the stack has TCP headers at one virtual address, user data at another, and wants to pass them to the driver as a list which is then combined with MAC headers and passed to the hardware using a DMA scatter/gather list.

The client software should not need to know about DMA operations. For example, scsi.device knows when and how to invoke StartDMA(), but client software such as file systems are not suppose to worry about that. The driver has to worry about the DMA issue. This is again a good place to put a hardware abstraction layer.

Quote:

How do we handle 32-bit devices that need physical addresses below the 4 GB boundary? Do we have software support for DAC on hardware that supports it? (Neither of those should be an issue at the moment, but as with 24-bit DMA, 32-bit DMA will necessarily be a special case in a 64-bit environment.)

It should be the driver's call how to allocate the memory in the most preferable form. Some restrictions will have to be observed by the driver, though. Such as that memory has to be allocated on a certain page boundary, and in a certain granularity.

Quote:

Receiving data doesn't sound too complicated, although small optimizations like padding the buffer to properly align the data portion of the packet, either on an appropriate word, page, or cache boundary, would have to be performed by hand. Standardized support for polling would be good, too. Interrupt processing overhead on a 10 GbE PCIe device, for example, would quickly saturate the system. It could happen with other high performance devices as well.

I know what you mean. This already happened for the fast Ethernet devices in OS4. Because the traffic passing through the interfaces has to be copied around, there is only so much that can happen before the CPU load interacts with the multitasking.

Quote:

We might also want to consider a way to pause the stack's transmit queue when an interface is saturated.

Roadshow currently has a policy that for every packet that comes out of the send/receive queue for an interface, and enters processing, only one other I/O request goes back to the interface. If enough traffic saturates the interface, packets will drop and the TCP/IP stack will adapt accordingly.

@olsen

About the fact to have the modem synced and dataed before switching on the amiga.

I haven't waiting this state and I have made just made one test (for information).

I know that I must wait the modem before running the amiga, for sure



Ibrowse: work well but some dns not resolved imediately.

Netsurf 3.0 dev: after a moment, a requester said: connection timedout.

OWB: Same as netsurf or do nothing forever and sometime even an empty window when loading OWB.


I know why but hope some warning could be added on roadshow on the futur, for users without informations (even if users who start slow internet with their amiga are just afew (surely).

_________________
BTW, what you have done for the amiga today ????

-A1200+Mediator+VooDoo3+060/50+96mo+SCSI-KIT
-SAM440EP-667mhz-on MapowerKC3000+AOS4.1

Amiga Docs Disks Preservation Project

@Mrodfr

Quote:

Ibrowse: work well but some dns not resolved imediately. Netsurf 3.0 dev: after a moment, a requester said: connection timedout. OWB: Same as netsurf or do nothing forever and sometime even an empty window when loading OWB.

For DNS you may well use the following (Open DNS) IP-address:
208.67.220.220
208.67.222.222

I got to know these two only yesterday and put them to good use immediately. They are not ISP dependent.

OldFart

_________________
More then three levels of indigestion and you're scroomed!

@Mrodfr

Have you used a POTS (plain old telephone service, i.e. dial-up) modem in the past? Would you try to access a bulletin board or web site before the modem completed its audible training sequence? In the case of DSL and cable modems, there's an analogous training sequence; however, the only indication of completion is the device's LEDs. Unfortunately, you just have to wait.

The IP stack is fully functional on your local system, via the loopback interface, even if it can't connect to the outside world. It's up to the web browser or other application to explain from its own perspective why it can't connect to the requested host.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603