Conference netcad::hub_mgnt

    You may have some Ethernet NIC's that are out of tolerance woth the
    IEEE timing specs.  They state that the clock should be 10 MHz +- 0.01%
    I think.
    
    The DECrepeater 90TS, 90T-16, 900GM and 900TM all have analog phase
    locked loops.  The 90T, 90C, 900TP, 900CP and DEMON all have digital
    phase locked loops.  Due to the ASIC design there are not enough extra
    bits in the FIFO and as a result the digital phase locked loops are
    very strick with timing.  You will see the problem with large Ethernet
    packets.  The timing gets farther off the longer the packet until the
    repeater says the packet should end but the sender isn't quite done as
    its clock is a little slow.
    
    Unfortinately some customers have old equipment and little money so
    they are stuck.  Sometimes they shop else where for network products
    that are a little more relaxed.
    
    I'm about to raise an IPMT on the 900TP as a university has problems
    with older equipment and these new repeaters.  The repeaters should
    receive relaxed but transmit tight.  Unfortinately it will take 6-9
    months to redesign the ASIC chips.  We can't afford to shut out
    customer's older equipment.
    
    dave

    
    Thanks Dave,
    
    		Frank Levesque from engineering has already been in contact
    with us regarding this problem. Your analysis of the problem is the
    same as he gave us. The question now is, what do our customers do in
    the meantime. We have arranged to send 4 ethernet adapters to Frank to
    try and get a "Work-around" for this problem. Unfortunately the
    customer involved has bought 50 units to Quote : "Try to save money"
    Apparently our Etherworks 3 cards were too expensive for him......
    Aaaaaargh.......
    
    Regards,
    
    Angelo.

    I would think that the customer would want to SEND THE 50 CHEAP ENET
    adapter back to the manufacturer themselves. It's not OUR direct issue
    that some garage-shop makes poor NICs. The NIC maker should be
    requested to return or exchange for a NIC known to meet the IEEE specs.
    
    In essence, the NICs are NOT MEETING the IEEE spec, and should be
    considered defective.... even if you can get them to work in some
    cases. IEEE SPECs are mostly explicit when it comes to the timing.
    It's the NIC makers problem, NOT OURS! (You are probably helping out to
    keep the relationship good, but that's all.)
    
    Has your customer tried sending them back?
    
    Mark

    re. .3
    
    >> It's not OUR direct issue
    >> that some garage-shop makes poor NICs. The NIC maker should be
    >> requested to return or exchange for a NIC known to meet the IEEE specs.
    
    Agreed.  Some vendors are very interested if their products don't
    comply and will work to correct.
    
    >> In essence, the NICs are NOT MEETING the IEEE spec, and should be
    >> considered defective.... even if you can get them to work in some
    >> cases. IEEE SPECs are mostly explicit when it comes to the timing.
    >> It's the NIC makers problem, NOT OURS! (You are probably helping out to
    >> keep the relationship good, but that's all.)
    
    Flame on.
    
    And what do you tell customers that have equipment in place BEFORE IEEE
    screwed up the specs????  I'm sorry mister customer but all your
    systems that have been in place since Ethernet V2 specs will have to be
    thrown out.  Duh!!  MARK, why don't YOU tell the customer to go out and buy
    DEMPR's or DETPR's?  Don't stop there.  Why not just tell the customer to
    throw out all your Digital components and get in 3COM or who ever can 
    accept equipment running a little out of spec??
    
    Flame off.
    
    The problem is simple.  The fix will take a little longer once people
    decide that it's THE RIGHT THING TO DO (sorry to drag the oatmeal guy
    into this).  Larry Walker made a comment about designing products for
    the future and I agree 110%.  However it goes a long way if, while we
    are designing for the future we also maintain compatability with the
    past wherever and whenever possible.
    
    The way you get the 2 objectives to work is as I mentioned in a
    previous reply, "RECEIVE RELAXED (backwards compatability for older
    systems), TRANSMIT TIGHT (designed for the future).
    
    This is the only way to give our customers INVESTMENT PROTECTION.  If
    you don't think that it's worth it, call me and I'll give you the name
    and number of my customer.  You won't be standing when he's done with
    you.  A university that buys a GIGAswitch, 900EF's and hubs and 12
    900TP's just for the engineering faculty can't be all wrong.
    
    dave
    

    Hello,
    
    I hope this note is still being watched as I had a similar problem.
    
    Customer had 900TM's and everything worked fine. Then 900TP replaced
    the TM and an IBM AIX could not access the LAN anymore.
    The AIX has an embedded Ethernet-Controller on the 7248 system board.
    
    After putting an Allied Telesyn 10-port repeater between the AIX and
    the 900TP things worked again.
    
    Will we ever see a fix for this ?
    
    
    Regards
    
    Ulrich Rueggen

    Just fyi - I've seen two cases where a 90t and a 900tp, both
    connected to the thinwire inside a dh900ms could not communicate.
    Replacing the 90t w/ a 90t-16 fixed the problem both times.