Date: Mon, 31 May 1999 11:28:01 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: maret@axis.de (Alexander Maret) Cc: hackers@freebsd.org Subject: Re: xl driver for 3Com Message-ID: <199905311528.LAA04262@skynet.ctr.columbia.edu> In-Reply-To: <91DA20EC3C3DD211833400A0245A4EA9BA0E43@erlangen01.axis.de> from "Alexander Maret" at May 31, 99 08:07:00 am
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Alexander Maret had to walk into mine and say: > Hi, > > > > If you have a real, detailed and accurate bug report to > > submit, then fine: > > let's hear it. But if you just want to make vague and unsubstantiated > > complaints, do me a favor and just keep it to yourself. > > I'm having serious problems with my 3COM Card too. The problem is > that there are many many collisions on the network. If i for > example transfer 30MB via samba from one computer to the other i get > about 900 collisions. I even get those collissions when only those > two computers are connected to one hub. If i transfer too many data > the NT machine crashes. If I transfer only a few bytes - say I'm > listening to an mp3 audio file which is on the server - then there > are no collissions. Frankly, 900 collisions for transfering a 30MB file isn't bad. Given that an ethernet frame can hold a maximum of 1500, that works out to around 20,000 packets. If you got 900 collisions out of 20,000 packets doesn't sound unreasonable. The reason you get collisions even if only those two machines are active is that they're only attached at half duplex. That means that if both machines transmit at the same time, they will trigger a collision. You don't have to have many hosts on a single ethernet segment in order to see collisions. For example, with a TCP transfer (which is what samba is doing), the server host will be sending enough packets to fill the TCP window (maybe 16K or so). The other side will then have to reply with an ACK for each segment that the server sends, It's possible that the ACK will be sent by the LoseNT host at the same time that the server is still sending data: that means there will almost certainly be collisions. If you had a full duplex switch, of if you had both machines wired back to back with a crossover cable and set both NICs to 100Mbps full-duplex mode, then you would never get any collisions at all (full duplex implies that both hosts can send simultaneously without ever colliding; in fact most chips disable collision detection when you program then for full duplex mode). How many collisions you see depends on a number of factors, including how fast the two machines are and how fast they can transmit data. If the receiving host is slow, then it will send ACKs slower, which will cause the sending host to throttle back a little (it can't send the next TCP segment until the previous ones are acknowledged). What you need to check is how fast the transfers are going. Observe the activity LEDs on the NICs and on the hubs while a transfer is in progress: if the LEDs keep flashing steadily throughout the whole transfer, then the NICs are working ok. If you see pauses during the transfer, where the LEDs stop flashing for a few seconds or more, then one of the NICs is getting stuck somewhere and having to reset itself. Run netstat -in on the FreeBSD host and look at the oerrors section of the output. If there are no output errors, then the NIC is probably working ok. Also, try and time the transfer: cound how many seconds it takes to transfer all 30MB of data. Ideally, you should be seeing several MBs per second. You can also try FTPing a file from the FreeBSD host to the LoseNT host; the FTP client should give you an approximation of the transfer rate. Bear in mind though that this will include the overhead of copying files to and from the disks. You can attempt to avoid this by FTPing the same file several times in succession (after you read it once, it should be cached on the server). Also, you can FTP the file to NUL: on the LoseNT host: this is equivalent to writing the file to /dev/null on UNIX and will not generate any disk activity. As for the LoseNT machine crashing, I can't really help you with that. You also didn't explain exactly what you meant by 'crash.' Does it just lock up completely (mouse doesn't move)? Does it 'panic' with a 'blue screen of death' (register dump)? Does the machine keep working but the networking stop (you can't ping it anymore)? -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905311528.LAA04262>