>> Possibly, so skip the 100 part.  That's pointless anyway on a small
>> microcontroller and with any modern ethernet switch.  You'd be hard=20
>> pressed
>> to find a ethernet switch nowadays that doesn't adjust its speed per=20
>> port.
>> That means you can connect the small embedded system at 10 Mbit/s, which=
=20
>> is
>> more than it can handle sustained anyway, but not slow down the rest of=
=20
>> the
>> network.  Or put another way, you're already paying for 10 to 100=20
>> conversion
>> capability in the switch.  You might as well use that to make the small
>> embedded system simpler.  Note that there is no loss of throughput since=
=20
>> the
>> small system can't keep up with 10 Mbit/s in the long run anyway.
>>
>
> While I agree with all this in theory, in practice I don't want my
> product to be the first and only thing that tests/requires the
> customer's 10/100 switch to work flawlessly at 10mbits for the port(s)
> it is plugged into.  Should it all be no problem, ever?  Yes.  Will it?
>  well... given the difficulty of doing remote support/troubleshoot of
> why "the switch works ok with everything else" but not my product I'd
> rather pay a little more and be 100mbit like nearly everything else in
> the common computer/IT networking world.
>
> Cheers
> J

I ran into a nasty problem with having a 10MBit device plugged into a 10/10=
0=20
switch. There was so much broadcast traffic on the network that the switch=
=20
couldn't send it all out the port. The 10MBit device had no interest in the=
=20
broadcast stuff. Random packets were dropped, including many directed to th=
e=20
10MBit device. Luckily the switch was a managed switch and it could be told=
=20
not to route the broadcast packets to the 10MBit port.

-- Bob Ammerman
RAm Systems

--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.