Well, it all started out innocently enough.  I decided that I'd like to
upgrade to a 486DX/33 motherboard from my current 386SX/20.  So, I got
a copy of Computer Shopper, and called all the places who advertised
motherboards, asking a bunch of questions about their offerings.  There
were several requirements for my purchase, foremost among which were:
1) The motherboard had to support at least 64MB of RAM *on the
motherboard*, without adding 32-bit memory cards or things like that;
and 2) The motherboard had to work with Unix.  So, after calling what
had to be 50 or 75 different motherboard vendors, I narrowed the list
down to eight vendors: CCSI, BSI, MicroLine, Essence, Wedge Technologies,
Motherboard Warehouse, MileHI, and A.I.M.  After doing some more comparisons,
I decided to get a motherboard from MicroLine.  Price: $644, plus shipping
and credit card surcharge.  So, I called MicroLine and after verifying
that they had the board in stock, I ordered it and charged it to my
MasterCard.

The problems started as soon as I got the board and unpacked it.  They
had shipped the wrong part -- I had specifically requested a motherboard
that could take up to 64MB of memory, but this board was limited to 32MB.
Somewhat annoyed, I called up the RMA department, who apologized for the
mixup.  It turns out that they didn't have any of the 64MB boards in
stock, and would have to order one from their vendor.  Would the cost
be any higher?  They didn't know -- the guy from the RMA department
said he'd have to check on it with their vendor.  This was last
Friday.  On Monday, I called again, and the guy was still checking.  On
Tuesday, I called three times, and was unable to get a hold of somebody
in RMAs -- the first time I was half an hour too early, the second time
was during their lunch break, and the third time he still didn't have
any information.  Finally, he called back late Tuesday night and told
me sorry, but their vendor no longer carries the 64MB boards.  Why did
the salesman claim that MicroLine still carried them, and even said he
had one in stock?  The RMA guy didn't know, so I just asked for a full
refund, and he was happy to give me one.  Well, I was a bit annoyed,
but I hadn't lost yet anything but time, so I wasn't too mad.

So, the next day I look at my list of motherboard vendors again, and
decide to try A.I.M. this time.  Things looked good -- they had salespeople
who actually spoke English well, they had a 30-day money-back guarantee
with no restocking fee, and they had an 800 number for tech support.
The board was going to be about $100 more than the MicroLine one, but
oh well, I guess that's what you pay for quality.  So, this time I call
up A.I.M. ensure they have the board.  No problem, says the guy, they
have the boards in stock and ready to ship.  He quoted me a price of
$169 for the board, $499 for the CPU, and another $70 for the cache
memory upgrade.  Fine and dandy, so I ordered it and charged it (again)
to my MasterCard.

Today at work, I get a call from A.I.M.  It seems that the person I talked
to on the phone last night was misinformed on A.I.M.'s product line; the
$169 motherboard he had quoted me only took 32MB of memory.  She explained
that A.I.M. manufactured its own motherboards, and had recently phased
out the 64MB motherboard for a 32MB motherboard.  I had two choices: I
could take the 32MB board for $169, or she could special-order a 64MB
board for "only" $70 more, or $239.  This sounded a bit fishy to me,
since the guy who took my order last night identified himself as the
president of A.I.M., and I would hope that the president of the company
knows what his company is selling.  I tried to explain to the woman
what the phrases "dishonest business practices" and "bait and switch"
meant, but the most she would concede was to throw in overnight shipping
on the motherboard for free.  Big deal.  Finally, I just decided to
cancel the order -- I may have been on the more legally solid ground,
but I don't think I want to give my money to a company that engages
in practices such as these.  Too bad, too, since they looked so
promising...

Meanwhile, in preparation for the new motherboard, I had ordered four
4MBx9 70ns SIMMs, to upgrade the computer to 16MB of RAM.  The salesman
at Pro Components claimed that the SIMMs they had in stock were Oki's,
and I agreed that that brand was satisfactory.  So, he charged my
MasterCard and sent the SIMMs out UPS Ground from Southfield.  Unfortunately,
when the SIMMs showed up on my doorstep today, they were Eagle's, not Oki's.
And they had the rather ominous words on the back, "Personal Computer
Value Series Module.  EAGLE Memories is the sole warrantor of this product.
Not for use in Medical, Military, or Mission Critical Applications."  However,
I decided to try them anyway -- unfortunately, they failed the POST memory
test in both PCs I tried them in.  Calling Pro Components again, the
salesman very quickly agreed that it was a compatibility problem, and
that he would swap the Eagle's for Oki's ASAP.  So quickly, in fact,
that I almost got the feeling that they had this batch of Eagle chips
around they were having trouble unloading, so they sent them out to
every customer who hadn't yet gotten Eagle SIMMs, with the knowledge
that there was a good chance they might not work.  Hmm.

And finally, after discovering that the Eagle SIMMs didn't work, I set
to work finding yet another motherboard vendor.  While I was looking
for my motherboard-vendor summary sheet, I happened to stumble across
some flyers that I had picked up at the JCC sale, and decided to call
the two companies: Competitive Computer Systems and Columbus Computer
Center.  Ironically enough, Columbus Computer Center had an acceptable
motherboard in stock, for less than the original MicroLine price!
So, I charged yet another motherboard (this makes three) on my
MasterCard, and it will ship from Columbus tomorrow morning.  I
never thought you could have this much trouble trying to spend this
much money.

And so the saga continues.  I'll update this item when my new SIMMs
and motherboard arrive.  Hopefully, they will be the correct parts
and work properly...

47 responses total.

  Unfortunately the business practices required to provide the lowest
cost merchandise in a market as competitive as the current clone market
can be rather dishonest.  You're just fortunate that you have an idea
what to watch out for; the vast majority of PC buyers don't.

You should have heard him on the phone with AIM today, with me and jep as 
his cheering section.  

(Pssst... I *told* you we had to RMA the only thing we ever bought from
ProComponents....  nobody ever listens to me)

Sounds really annoying.

We'll pray for you.

Re #2: (Psst...Yeah, but Walt said that was because we ordered the wrong
part in the first place...)

Yes, really annoying.  I'm in a bit of a better mood this morning than
I was last night, but I'm still rather annoyed.  For those of you
planning on buying a computer or motherboard: Stay away from A.I.M.
The MicroLine problems I could understand; they seemed rather disorganized,
and were happy to refund my money.  A.I.M., on the other hand, seemed
VERY organized; almost as if they had PLANNED to do something like this.
Hmm.

i'm very surprised that you've had all this trouble, honestly.  after all,
the trend seems to be towards more and more r.a.m.--i recetly read an ad
for a computer that would take 128 mb on board. wow. why any company would
be building boards that take half as much ram as their predecessors really
eludes me.

Would you be utilizing all of the memory?  I can see that this can be the case
when you have uucp running in the background and you are compiling in batch
while you do your accounting.

All of 16MB?  Yes, I will be.  I'd like to play around with X11R5, and
according to some reports I've heard, it uses around 15MB of memory.
The GCC optimizer can take up over 1MB of memory.  And, of course,
X clients are memory-hungry as well.

The reason so many places sell 32MB boards is that they can make
baby-size boards much more easily that way.  It's fairly difficult
to find the board real estate on a baby-size motherboard to fit
16 SIMM slots, which is what you need for 64MB.  And after all, those
DOS weenies think 8MB is a lot, so why bother spending extra design
time on a feature that maybe 15%-20% of your customers will use?
Personally, I don't really care if the board is baby-size or full-size,
since I have a fullsize case.  So I'd be happy to buy a fullsize
motherboard, as long as it could take up to 64MB of RAM.  But alas,
those boards have a much more limited market than the baby-size
32MB boards, so the prices are higher.

It sounds worth it though.  I assume that the memory has parity checks
to be able to detect memory faults.

(Heh, if this company were smart they'd have Tony Randall in all the
trades hawking these "Eagle Brand Chips")

<loud laughter>

If you get past the first hurtle, you can count on many more.  My 
experience with '486 motherboards is that none of them (so far)
work entirely.  I've tried motherboards from A.I.R, Pioneer, Young
Microsystems, and DTK.  So far the DTK has worked the best.

Yeah, DTK.  That's good news.  I have a 386-25.  It works wonderfully.

Interestingly enough, the only comment I have on DTK motherboards
from the net is that they are, quote, "dogshit".  They apparently
cause lots of spurious interrupts that DOS ignores, but that positively
drive Unix up the wall.

I got the motherboard from Columbus Computer Center today, and it
works fine.  I think I may be satisfied yet...

Well, I had two DTK motherboards that I couldn't get to work on netmeg last
week, and when I called their tech support dept about jumpers and so on,
and the tech was looking at the specs for the board, he said "Wow, this is
really retarded!" which didn't leave me with a lot of confidence about DTK
in general.

NOW you tell me.  Well, it still works great with DOS.  I'll remember that if I
ever use it for anything more sophisticated (NOT!).

Well Marc may have the "Motherboard and Memory From Hell" title locked 
up, but I triple dog dare anyone to beat my "Modem From Hell" 
championship.  I'm just about to RMA my third Supra V.32bis (the tech
person listened to it on the phone and said it was obviously "sick" )
for a fourth try.  This is the last down, if the one I get on Friday
doesn't work, I'll punt.

After reading comp.dcom.modems for the last couple of months, I've
pretty much written off Supras.  I'm thinking Zoom or USR.

I heard somewhere (here?) that zooms are too sensitive to noise.

Rumors are, that there are ROM bugs with the Supras yet (they are
upgradeable) and some folks have trouble connecting at 14,400.  I have heard
this 14.4 problem in combination with fax modems before, and I think it has
to do with the specs being close for faxes and modems I think, and the
modems seem to get confused about who they are talking to (fax/computer).

I had an eye on them, since it offers caller id (!) later this year.
It may work if there is a way of shutting of the fax features all together.
That's the part I am interested in anyway.

Well, the third motherboard (from Columbus Computer Center) doesn't work.
It has an annoying tendency to lock up the keyboard after you've been
using it for 30-45 minutes.  Oddly enough, the rest of the machine is
still running -- I can flip on my terminal next to the computer,
log in, and continue what I was doing.  But nothing I do seems to get
the keyboard back.  So, this motherboard is going back, and I'm going
to get a Wedge Technologies motherboard.  Sigh.

My memory *did* come, though, and *it* works fine...

There was a few FAQs for 386/486 Hardware and Software.  Did you run accross
them?  It says DTK is bad, but I don't remeber seeing anything about CCC.
Is that their own product?

Back to Pro Components, they are no longer our memory supplier as of last
week. They insisted on sending us 70ns 1Mx9 SIMMS when after three
phone conversations we thought we had it pretty clear that we needed
100ns SIMMS. This was also not the first time of screw ups like this.

        Chris, you needed 100 ns and nothing faster?  They probably couldn't
get 100 ns SIMMs; I don't think anyone is making them any more.

yea, it sounds like you got a break - keep em!

Four times must be the charm.  Marc's fourth motherboard works ok, and my
fourth modem works fine.

That proves it! There *is* a 4th dimension, Einstein was right! Time
and time and time again ........

Yep, my Wedge Technology motherboard is purring along.  Three days
straight and not a crash...I think I'm going to like this.

Too bad I had to pay an extra $100 for quality.  Oh well...

What is the data?  How many MBytes available on motherboard, CPU/speed,
bus type, expansion slots, etc..  Also, what is the highest baudrate
it can go?  I heard that 386 boards can go up to ~ 110,000 bauds.

Up to 64MB on the motherboard; 486DX; 25MHz, 33MHz, or 50MHz (crystal
and CPU change required); ISA bus; eight 16-bit expansion slots.  I'm
not sure what you mean by "highest baud rate"; this motherboard doesn't
have a built-in serial port.  Highest baud rate through an RS-232 port
is more a function of getting a good serial driver and a good serial
port, preferably with a NS16550AN UART.  I have an AST four-port serial
card plus a standard COM1.  I have no problems running a mouse on COM1,
a terminal at 19.2Kbps on the first AST port, and a modem at 19.2Kbps on
the second AST port.  Of course, I'm running Unix and the SAS serial driver,
but...

That sounds like a great board Marc,  the baudrate I mentioned was mentioned
in relation to msdos.  I don't know how unix rates, I would expect more
overhead, but on the other hand probably better ability of processing
data while it is pouring in.

Baud rate is not a function of the operating system.  It is dependent
on the ability of the hardware comprising the serial port.  Interestingly,
baud and bps are not the same thing: baud is the rate at which the device
can change from one state to another represented as changes per second.
BPS is the number of bits per second are sent or received serially.
In the case of baud, one change of state can represent more than one
bit.  For example, our 2400 "baud" modems actually operate at 1200 baud
and 2400 bps.

Well, it is hard to draw the line on the dependency of the OS.  The max
rate is not olny a function of your hardware port, but also a matter
related to how fast can you pickup the data that comes in.  There the OS
comes into play.  Different OS have different strategies to cope with
high speed serial lines.  Some of these strategies involve being just
barely fast enough to pick up the data, and turn the flow off before you
start loosing data.  So, there is also a rate which you can sustain,
sometimes different than the max rate.  It also would depend on the
application and how much time it needs to digest the data.

As for bps, and baud, although not stated explicitly, the measure should
apply to the bitstream at the computer port, regardless of how much
data is shuffled thru.  The flowing data could be compressed or otherwise
encoded which may result in higher or lower amounts of end data going
into the computer.  Usually, with the RS232 type connection definition,
there are a few more state changes per byte which helps with the bit framing
and parity checks.  Most systems are adjustable on how many bits to send in
one frame, whether or not to send parity information, and the kind of
frame to use.

So when you convert from the baud measure to the bits or bytes transferred,
you will end up with less, unless there is some sort of compression
protocoll involved.  There are programs on PCs which can send differentt
frames than the RS232 tty framing (startbit, bits, parity, stopbit)
resulting in higher data thruput at the port (not necessarily compressing).

What I am interested in is the baudrate that a system can handle, in other
words the hardware limitations.  For example, it is not a measure if the
port can handle that many interrupts associated with the baudrate (more or
less baud/10) but the system design does not let the CPU pick it up at that
rate and stack away.

  If you pay attention to what the other responses are saying, they're
trying to tell you that maximum serial throughput is not a function of 
the operating system but is a function of (a) the serial port hardware
(most importantly the UART), (b) the programming scheme used to grab
stuff from the serial port, and (c) the amount of processor power available
to do said grabbing and then do something meaningful with the data.
The OS is generally not a consideration since if you don't like the way
the driver that comes with the system behaves, you usually have the 
option of replacing it with something else.

yeah.  Plus if you're cool, you can write your own interrupt handler that can
deal with very fast data rates by implementing a buffer.  Some serial ports
and UARTs have the buffer built right in.  The only time I use the BIOS or DOS 
serial port functions is when I need something quick and dirty.

Well, if you suggest being careful, read it carefuly yourself mcnally.  It
is not a black and white description you can make.  I want to know how many
bytes of stock tty protocoll the system can handle.  I know that you can
increase the thruput by changing the framing and applying software
compression.  That is not attributed to stock hardware and driver design.
You can split your driver into two parts to achive max response to the
interrupts, but that is not what you buy.  With your argumentation, some
salesperson could say that this board xyz can handle 20,000 bytes per second
thruput, where he has written something entirely in assembler optimizing the
serial interface thruput to the max.  But that is not what you buy, and it
is not going to perform that way in your system.

It is difficult to drive a line between OS dependency and hardware
attributes.  I have seen some hardware designs, where the serial port stuff
was going thru some other multi function IC, which limited your bits per
second number by design, although the UART could do a lot more itself.
There you will be limited by the design, and not the UART.

Basically, I stated what you summarized under a,b,c.  Serial port hardware
(a), stock driver of the OS (b), keeping up with the data (c).
What are you objecting?

  That's not what you said at all..  You started off asking Marc how
many "baud" his motherboard could handle, and stated that you believed
386 boards could go up to "110,000" (presumably bits/second..)

  Other people pointed out, quite correctly, that (a) the terms "baud"
and "bits per second" are not interchangeable, and (b) it's meaningless
to ask what sort of serial thru-put a motherboard can get without first
determining what sort of serial interface will be used and what sort of
software will coordinate communications between the processor and the 
UART.  Your original query certainly didn't specify how you expected
to fetch the data (and "the standard way for an MS-DOS machine, if there
is such a thing, isn't going to be particularly applicable since Marc's
going to be using Unix on his system)

  Finally, you keep trying to bring in completely irrelevant factors..
The best example of this would be your talk about "software compression".
Compression has no bearing at all on how quickly bits can be transferred
from the computer out the serial port; instead it is a matter of how much
information those bits represent when uncompressed.

If you throw a new clock or crystal on an IBM serial board, add a transistor
and an op amp with some resistors thrown in for good measure you get a darn
cheap MIDI interface for your PC.  Have to write your own software though.
You don't really need the op amp if you bypass the line drivers on the board.

There are several factors which affect how much data you can shove
through a PC-style serial port:

1. CPU speed.  This mostly manifests itself in how fast the serial driver
routines get executed; if instructions get faster, then you can afford
more instructions to handle each byte.

2. Serial driver.  A good serial driver (i.e., one that uses fewer
instructions per character) will be able to handle a higher speed than
a bad serial driver.

3. OS.  This has to do mostly with things like interrupt latency and
such.  If you're getting one interrupt per received character, it
doesn't matter that your serial driver can process that character in
10 instructions if it takes too long for your routine to get called
on the next interrupt.

4. Serial port hardware.  A port using a buffered UART (NS16550AN, for
example) can make up for higher interrupt latency times and sometimes
a bad serial driver.

Of these four factors -- and I'm sure there are more, but these are
the main ones -- the only one affected by your motherboard is CPU
speed, and this is only affected indirectly by motherboard brand.
All the other factors are independant of motherboard brand, which
is why I didn't think your question made much sense.

Now, MS-DOS has a pretty awful serial driver.  It just uses the
calls in the BIOS, which are in turn pretty awful.  They don't
do any buffering, and can only handle about 30cps without dropping
characters.  There are a lot of people who have written replacement
serial drivers for MS-DOS that implement buffering, use the FIFO
buffers on the NS16550AN, etc.  Unfortunately none of these are
standard or built into the OS, so it's pretty much a toss-up as to
whose driver you get.  It also means that if you have a program
that is getting low throughput because of a bad serial driver, there's
not much you can do without the source to the program.

Unix, on the other hand, has the serial driver as part of the OS.
Programs can't talk directly to the UART; it just isn't possible.
So, you don't have to implement your own serial driver under Unix
to talk to a serial port, and you also don't have to go grovelling
around in each program to make it use a different serial driver.

Unfortunately, the stock asy serial driver included with most versions
of System V/386 is pretty bad, too.  Most of them don't handle the
NS16550AN, and although it's better than the BIOS routines, you still
can't go much higher than 480cps without having problems.  SCO,
notably, rewrote the asy driver (calling their replacement sio), and
it's much better.  It supports hardware flow-control, the FIFO buffers
in the NS16550AN, and so forth.  It's not perfect, but it's a lot better
than the AT&T driver.

There is a public-domain serial driver called FAS, for Final Async
Solution.  It has been optimized for speed and efficiency; it also
correctly handles hardware flow-control and the NS16550AN.  There
is a STREAMS adaptation for SVR4 called SAS.  Most people running
System V on PC hardware will want to get FAS or SAS if they're going
to do any serious work with a modem, or use a serial port at speeds
over 9600bps.  SAS is what I have installed on my SVR4 box.

The baud vs. bps issue is not valid when talking about RS-232 ports.
The UART used in the PC, when set up to interoperate with most common
modems and terminals, sends 10 bits per character.  Each bit requires
one signal change, so bits per second is equivalent to bauds (remember,
a baud is a state change per second).  Of those 10 bits, one is the
start bit, one is usually the stop bit, and then you have either 7
data bits and one parity bit or 8 data bits and no parity bit.  So,
to convert from bauds to characters per second, you can USUALLY divide
by 10 -- assuming you are sending 10 bits per character.

Now, this has nothing to do with the modulation and protocol used by
the modem.  We're talking about the PC<->modem speed, not the
modem<->modem speed.  Bell 103J modulation (300bps), 1 bit = 1 baud,
so 103J is still properly 300 baud.  However, Bell 212A is 1200bps,
but 600 baud -- there are two bits encoded in each state change.
V.22bis is 2400bps but still 600 baud; this time there are four bits
encoded in each state change.  V.32 and V.32bis use higher baud rates
and more bits per state change to get 9600bps and 14400bps.

Now, if you're using V.42 or MNP level 4, you're actually running 
a synchronous protocol between the modems, instead of the normal
asynchronous protocol.  So you no longer need start bits and stop
bits for modem<->modem comm.; you still need them for the PC<->modem
transfers.  When the modem sends the byte, it strips off the start
and stop bits, meaning that you no longer have 10 bits per character,
but 8 bits per character.  So your modem<->modem throughput goes up
by 20%, assuming you can feed characters into the modem fast enough.
This is where having a DTE<->DCE speed higher than your DCE<->DCE
speed comes into play, and this is why hardware (RFR/CTS) flow control
is important for fast modems.

Although I'm not a PC unix man, I find it impossible to believe that your
programs could not access the hardware ports if you wanted them to.  How
could you develop any new hardware/software to utilize the I/O bus if this
were true?  It makes no sense.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss