Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Tech docs | Downloads | BBC Micro

Simtec and friends shift 1000th NET100

By Chris Williams. Published: 27th Oct 2003, 19:42:15 | Permalink | Printable

Cue one special offer

Simtec and their OEMs are celebrating tonight after shipping their 1000th NET100 card. The NET100 is a 100MBit ethernet card for RiscPCs and A7000s which first went on sale in March 2002. To put the value in perspective, going by RISCOS Ltd. estimations, there are about 4000 RISC OS 4 users.

As expected, there's a special offer involved. Every NET100 card purchased before 24th December this year will be a thousand pennies cheaper than the normal retail price. A thousand cards produced, a thousand pence off the retail price - that has to be the biggest coincidence of the year.

AdvantageSix and R-Comp both resell the NET100 cards to RISC OS end users. Simtec would appear to like this arrangement seeing as they're now involved in a lot of ARM based embedded work, it makes sense to channel their RISC OS focused products (like their USB podule kit) through well known dealers. Incidentally, it was revealed earlier this year that AdvantageSix (as STD) had sold over 2500 PS2MiniMouse converters.

Skimming through the press release, the best quote comes from Andrew Rawnsley of R-Comp for stating: "The 1000th card is symbolic of the fact that co-operation in the RISC OS market works for all involved, and that the market is in a stronger state now than it has been for a while". Stuart Tyrrell of AdvantageSix also said that, "without a doubt that the core RISC OS market remains buoyant".


Simtec website

Previous: Cino aims for Q2 2004
Next: VirtualRiscPC network upgrade pulled


Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

This is great news, also the price of a 2nd hand 10baseT has now dropped from a rather stupid 70quid to about 20-30. So a big thanks to all those who upgraded and saved me a packet :)

 is a RISC OS Userflibble on 27/10/03 8:56PM
[ Reply | Permalink | Report ]

flibble: My pleasure, I bought three and used two (the other is on loan).

The 1000th sale is a pleasant celebration of yet another technological (and commercial!) success of RISC OS companies based in the north-west.

On the other hand, it's worth remembering that this is a hardware add-on aimed solely at obsolete 26-bit machines. So the 2000th sale just isn't going to happen.

Gigabit cards are the way to go, even if the Iyonix does have one built in as standard...


 is a RISC OS Userdgs on 27/10/03 10:39PM
[ Reply | Permalink | Report ]

It would be even better if the card didn't suffer a hissy fit every so often and go into Mbuf exhaustion overload. Although, of course, this is "Acorn's fault"TM.

 is a RISC OS Usermikeg on 27/10/03 10:41PM
[ Reply | Permalink | Report ]

If it's running out of MBufs, you can manually softload the MBuf manager, giving it parameters telling it how many buffers (small and large) to allocate. Probably wise to have more than the default on a faster ethernet card.

*rmload system:modules.network.mmanager 2048 128

 is a RISC OS Userimj on 27/10/03 11:28PM
[ Reply | Permalink | Report ]

I'm certainly very happy with mine. It causes two lights on the desktop switch that sits to my right to light up quite perfectly.

It's a shame that I haven't yet got round to persuading the PC to accept its Network card quite so easily, or indeed to accept an operating system. Something to do with IRQs and lack of RAM respectively, I suspect. While it certainly was a PITA getting that metal panel out of the back of this RPC, I still can't say it was anything like as hard getting the NET100 installed and recognised by the computer.

 is a RISC OS Userninja on 28/10/03 12:15AM
[ Reply | Permalink | Report ]

It's rather bizarre that MBufManager doesn't adjust its memory usage depending what's going on, was this due to complexity or just that it was assumed 10MBit was the fastest speed to be used? If the spec is available then it could alwyas be reimplemented to adjust its allocation as it runs :)

 is a RISC OS Userjohn on 28/10/03 12:50AM
[ Reply | Permalink | Report ]

Out of interest has anyone actually seen a gigabit network card on a PC? I've only ever seen 100/10 type cards. -- Smiler - :D Alex Melhuish

 is a RISC OS UserSmiler on 28/10/03 6:39AM
[ Reply | Permalink | Report ]

imj; Why should I have to? Surely this is the sort of issue that should be transparent to the user, and addressed by the manufacturer? john; 10Mbit cards did the same. The answer there was to go to Configuration -> Memory and increase the System Heap/ Stack level. 96 rather than the default 32 was about right.

I had just hoped that this was the sort of thing that would be addressed by new hardware.

Additionally, I have had problems caused by the way the MAC address is created. Again, of course, this is Acorn's Fault.

 is a RISC OS Usermikeg on 28/10/03 7:32AM
[ Reply | Permalink | Report ]

Mikeg: You know that mbuf exhaustion is caused by a misconfiguration of RISC OS. Whilst there are published work-arounds for the worst offender (OS3.7), these have a detrimental effect to later versions where the problem within RISC OS has been fixed. New hardware makes no difference - and it's certainly not good practice for a hardware manufacturer to assume they can apply a software patch, which may or may not be appropriate, magically in the background. The only thing one can do, given the limited number of people this affects, is to modify user documentation.

You had MAC address problems because you were using RiscPC's from which a chip, which is a specified and required part of the machine, had been removed (thus also breaking other applications such as PhotoDesk). That certainly wasn't Acorn's fault!

 is a RISC OS Userstdevel on 28/10/03 7:52AM
[ Reply | Permalink | Report ]

Smiler: Some PCs (and some servers) do come with one or more gigabit ports built in. But it's much more common for people to buy the cards separately, as they're not vastly expensive. They're not all that widely used though, as not all switches support gigabit anyway - and 100Mbit, like 640KB, is thought to be "enough".

(I'm using 100Mbit connections for some of the servers I've bought that have gigabit built in, as the ones with less data throughput requirements can't justify using up a gigabit capable port on the switch).


 is a RISC OS Userdgs on 28/10/03 7:55AM
[ Reply | Permalink | Report ]

mikeg: I must apologise to Mike for the comments above. We just do so well with the NET100, and then we get a spate of "moaning" from a small number of people who would rather "feed back" to us in a public forum rather than contact us directly. Developers can only offer advice etc if people bother to contact them for it.

Mike *is* someone who offers direct feedback, and I apologise for using information gained via that to illustrate the point I wanted to make (but I mean, who goes around nicking machine ID chips? ;-) )

 is a RISC OS Userstdevel on 28/10/03 8:53AM
[ Reply | Permalink | Report ]


Why? Do you want some? ;-)

-- Spriteman

 is a RISC OS UserSpriteman on 28/10/03 9:17AM
[ Reply | Permalink | Report ]

Spriteman: No, not after that internet appliance design you sold me - you said that it was the only one of its kind! :frown:

 is a RISC OS Userstdevel on 28/10/03 12:57PM
[ Reply | Permalink | Report ]

I am having trouble with my old ANT NIC (RPC Combi) to access any network.

All tests are ok, but it wont even connect to another RiscPC (Ping..)

So I have decided to go for a Net100, but will it enable me to connect to my windows XP network WITHOUT difficulty?

I feel that this would persuade me to purchase one now as apposed to next year

 is a RISC OS Userem2ac on 28/10/03 2:11PM
[ Reply | Permalink | Report ]

em2ac> sounds obvious, but have you ensured that there are no faults with the cables?

I am using a NET100 on my RISC OS/Linux/Windows network without problems.

 is a RISC OS Userjonix on 28/10/03 3:01PM
[ Reply | Permalink | Report ]

I was thinking of buying a NET100 too, but seem to recall there was something like the Podule one is "better" (faster?) than the NIC slot version?

 is a RISC OS Usersimo on 28/10/03 4:29PM
[ Reply | Permalink | Report ]

stdevel: The problem I had was not that the ID chip was missing. Two machines, from memory, were getting the same address because of a problem with the ID chip. Which problem is mentioned on the Simtec site now, I note.

It would be nice if I did know that "mbuf exhaustion is caused by a misconfiguration of RISC OS". I get it on this box quite often, and have never had this information before. As I said, we used to clear it on older NICs by increasing a memory setting, but you can't do that from the GUI in RO4. druck, I think, posted a fix once, but it was a fix rather than a solution.

 is a RISC OS Usermikeg on 28/10/03 6:03PM
[ Reply | Permalink | Report ]

simo: The podule version is 32-bit, whereas the NIC slot is only 16-bit. However, I believe the difference is negligible in practice.


 is a RISC OS Userdgs on 28/10/03 6:55PM
[ Reply | Permalink | Report ]

druck did indeed suggest a fix (along the lines above) and it does help. However, there is clearly a flow-control problem in Access because an IYONIX at full tilt can still overwhelm a SA RISC PC during file transfers.

Something else that can help is turning down the 'Next' memory slot; Filer Action then works inefficiently and slows the RISC PC sufficiently that large transfers do work. I use values under 100kB and initiate transfers from the RPC (even if the data is coming from the IYONIX). Slow but generally reliable.

I try to forget that it defeats the object of buying the 100Mb/s card in the first place :-(


 is a RISC OS UserTonyStill on 28/10/03 7:03PM
[ Reply | Permalink | Report ]

mikeg: Didn't we talk the RISC OS MBuf issue over on the phone? I think you were sitting on a primary school chair amongst the "little people" at the time, so things might have been a little fraught ;-)

MBuf exhaustion is the bane of RISC OS networking, and although faster cards like NET100 perform much better in this respect than other cards, only Select goes any way to tackling the problem (and even then we should have dynamic MBufs rather than a fixed space). Users of earlier versions of RISC OS, especially 3.7 should heed IMJ's advice, perhaps even doubling the numbers he suggested if memory permits. A decent quality switch seems to curb Access' over-amourous advances towards mismatched machines a little.

I won't comment on the NIC vs Podule "debate", other than to muse that one might expect an advert which said "The only 32-bit RISC OS network card" to also say "The fastest RISC OS network card" if that were the case. There's no substitute for well-grounded bottom-up design.

1000 users can't be wrong :-)

 is a RISC OS Userstdevel on 28/10/03 7:28PM
[ Reply | Permalink | Report ]

Smiler: yeah, I've seen Gigabit in PC's (about $20 for a card) but have been underwhelmed by it - usually only seems to get 200Mbps not 1000Mbps, due to protocol overhead and other bottlenecks I guess (PCI bus? Cat5e? Drive throughput?)

Although Gigabit over fibre between the Suns at work is much faster according to our Sysadmin - but we're not sure if that's because it's fibre, or SCSI RAID, or immensly powerful servers.....

There are a few mobo's now with 1000BaseT onboard, but switches are out of home user price range.

I'd like to see 108Mbps wirelessG+ for RISC OS next please! ;)

 is a RISC OS Usersimo on 28/10/03 7:45PM
[ Reply | Permalink | Report ]

People seem to want to have an MBuf manager that can continually extend its buffer if it requires more space. This has some quite obvious problems. If the MBuf space can extend continually to accomodate the incoming packets you're going to reach the point where the machine is saturated.

There isn't physically enough bandwidth available to deal (on a RPC) with 100baseT data. Therefore in a fast communication, there will be some data that's dropped. This means that packets may get fragmented and require resending by the source. The fragments of the packets which are received will be held on to in Mbufs until sufficient time has ellapsed for them to be considered 'lost'.

Consider a UDP packet of (say) 16k (no relation to real data - I'm making these figures up at the moment and you should consider this only as an example) being received into a card with an 8k buffer. The system can't receive the data fast enough - it just can't. So it only gets the first 8k of the 16k UDP packet. Maybe it gets the first 12k because it managed to time its access well and so received first 4k before the next 4k arrived (again, 4k is an arbitrary figure and does not relate to the network MTU - the maximum transfer unit per protocol data packet). These chunks are all present, so it queues these for the Internet module in MBufs.

Lots of these transactions happen, and then Internet starts processing the input. It reads the packets and after trying to reconstruct the original data decides that it cannot. The UDP data is all present for 0-8k, but 8k-16k is still missing. So it leaves it in the queue waiting to be reconstructed when the packets arrive.

This data just hangs around waiting to be reconstructed until the tail end arrives (which it won't because this is UDP) or it times out - after a few seconds. Meanwhile, more data's coming in. Eventually the MBuf space becomes full and there is no possible way to receive more data. And you get an MBuf exhaustion error.

Now, consider that you've got an auto-extending MBuf system. It keeps extending. Taking up all your memory for just about no purpose - the packets cannot be reconstructed because they've been lost. Even if they /could/ be reconstructed, the receiving application may not be able to do anything about it because it can't claim any system memory to put the received data in to - MBufs have used the entire memory.

Even in the case where the packets are reconstructed in a timely fashion, allowing the entire system memory to be taken over by partial network packets doesn't seem like an entirely sane route. Better to limit the MBufs to some setting which has been found to function.

The default settings for a 100baseT may be too low, and you might like to experiment. But do understand that it may not be *possible* to locate a setting which can accomodate the data rate - as stated above, the data may just be lost.

[ In the above examples, UDP has been cited. UDP is intentionally 'unreliable'. UDP packets may arrive. They may not arrive in order, or they may not arrive at all. If they don't arrive, they're not resent. TCP is different. It includes sequence control for ordering and guarentees that data will arrive - either the data arrives or the connection has been severed. The mechanism for this can be found in te relevant RFCs or numerous books and websites. Essentially, TCP will be able to retry when things 'fail' so the data should arrive more reliably. However, this is is not to say that it does not suffer from the above fragmentation problems. It's just less severe. ]

I'm writing this off the top of my head without reference to anything else, so it's possible I've missed something in which case, I'm sure someone will point it out.

 is a RISC OS UserGerph on 28/10/03 8:06PM
[ Reply | Permalink | Report ]

Gerph: Yeah, where does Access and it's "you didn't hear me, so I'll SHOUT LOUDER" flow control fit in ;-)

I suspect the reason why MBufManager has its defaults set so low is that fixed buffers take memory, and memory is/was expensive. A dynamic solution, between certain limits, is possibly a compromise - in most cases a lightly loaded system might need only a small buffer, but for the fractions of a second when Access starts SHOUTING more might be available. I realise the difficulties of writing such, and the fact that the memory would need to be "available" anyway. The only real solution is to persuade users to allocate more MBufs and/or use protocols which aren't prone to SHOUTING ALL THE TIME - I suppose we're trying to change working things to accommodate the broken. As I've said, using some decent external flow control can stop some of the anti-social behaviours.

The real issue is that fast networking needs substantial buffering - however if machines shipped with hundreds of K "missing", people would complain. Probably in the newsgroups and on Drobe ;-)

 is a RISC OS Userstdevel on 28/10/03 8:44PM
[ Reply | Permalink | Report ]

stdevel> Access(+) (ie ShareFS) is entirely UDP based; if it isn't getting replies it will try its messages again.

All UDP protocols which expect responses must implement a form of flow control. The Access design is based around that for RemoteFS which was itself designed for... simpler systems.

I wouldn't say that it was shouting as there's no indication that the Access messages are any more important at the UDP layer than any other message (they're not flagged with any other delivery options than the default).

 is a RISC OS UserGerph on 28/10/03 8:49PM
[ Reply | Permalink | Report ]

simo: Yes, eight of the latest UltraSPARC-III (not i!) processors and sixteen GB of RAM seems to work fine here with multiple gigabit interfaces. Sun have admitted for a long time that serious processor power is necessary if you want to use serious networking...

... which rather rules out ye olde StrongARM Risc PC, as far as gigabit is concerned.

There's nothing exclusively clever about Sun's "ge" interfaces, we've found the "ce" varient to be useful too, on occasion. (Should one assume these mean "gigabit [fiber] ethernet" and "copper [gigabit] ethernet"? Not necessarily, but it's convenient shorthand :-) ).

You do need decent disk subsystems if you want to move very large amounts of data around very quickly. We use a Symmetrix at each site, supplemented by 3310 arrays for less performance critical stuff.

As you suggest, gigabit ethernet on mere PCs would often not produce the potential performance benefits one might imagine (but then, neither does 100Mbit on a Risc PC).


 is a RISC OS Userdgs on 28/10/03 11:09PM
[ Reply | Permalink | Report ]

Smiler: At work we use gigabit copper and fibre to its full potential on even rather modest PCs (Dual Xeon). Whooptydoo. :)

 is a RISC OS Userimj on 29/10/03 1:02AM
[ Reply | Permalink | Report ]

You cant solve the UDP problems that gerph mentions, but you can almost completely alieviate the exhaustions by substantiall increasing the large and small mbuff allocations.

As we are no longer running 1MB machines we dont need to restrict the pool to 200K, and can easily give it a megabyte or more.

When using Access as long as each transfer burst is quite short, it will continue without problems. With the default mbuf poll you have to reduce the wimpslot of a filer copy down to its monimum of 52K. If you quadruple the pool, the filer action slot can be around a megabyte quite happily.

I posted instructions on how to increase the mbuf pool to the Select mailing list and newsgroups a while ago. A smartgroups or google search should turn them up.

 is a RISC OS Userdruck on 8/11/03 2:05PM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

  • Cross platform development
    Building RISC OS Programs on Windows
     47 comments, latest by EasyKees on 07/10/04 8:05PM. Published: 24 Sep 2004

  • Random article

  • Freeware roundup
    Open source web browser fun. Enigma simulator. Stronger help and more.
     Discuss this. Published: 11 Jan 2003

  • Useful links

    News and media:

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster


    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign

    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "Drobe's only failing is the sixth-form geek-journo tone with its lead balloon humour and occasional smugness and ugly personalty"
    Page generated in 0.3054 seconds.