RE: xl driver for 3Com
If it had no backing then how could it be a fact? I assume that if you report that a card fails to work that that is true. That makes it a fact, e.g. my seat is red, but I'm not going to send you a picture to prove it. replacing the cards with intels and having the problem go away is backing. It may not be *useful*, but it is backing. Backing of the fact that there is a problem that you need to solve in a limited amount of money, yes. No backing of the fact that the problem is caused by the xl driver, e.g. if a card is not well seated you solve the problem as well by replacing the card. Nick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
Of course now that you've publically badmouthed us Im sure your requests well get very high priority :-) This is very unprofessional. I hope I shall never have to order from your company, and will advice others of this as appropriate. - Marius - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
Dennis den...@etinc.com writes: We have thousands of boards installedmaking them work back to back in a non-standard configuration does not make the product *better*, particularly when working with someone who cant provide useful info on *why* it doesnt work. I wish I could stop what I was doing every time someone had a problem, but I dont have that kind of time. Wow... lemme pull out my replace-o-matic: We have thousands of FreeBSD installations. Making them work with broken hardware / software does not make the OS *better*, particularly when working with someone who can't provide useful info on *why* it doesn't work. I wish I could stop what I was doing every time someone had a problem, but I don't have that kind of time. Neat. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: xl driver for 3Com
Hi, Well maybe FreeBSD is transmitting packets much faster than Linux. :) You still haven't actually measured the transfer speed, so there's no way for us to know. Well, I'll do and report the results to you. Grrr. I'm sorry, but I really don't think you're putting the pieces together correctly. Setting the NT machine to full duplex should have absolutely no effect on the FreeBSD host. It will completely screw up performance since the LoseNT host will then no longer be set to match the hub, but that's another problem. I strongly suspect that you're not making the proper observations when your problem manifests and just leaping to the conclusion that setting the LoseNT host to full duplex crashes the FreeBSD host. I just tell you what i experienced. I don't think that's true. Why are you ignoring problems. On the one hand you want people to use your driver and complain if they switch to other cards and on the other hand you comment their problems with: That's not true. I don't think that so many collisions are normal! I think there is a problem, because at work we nearly only use 3COM 100 Mbit cards and don't have much collisions. Even under high load! Looking at the fact that at work not only two computers are connected to one hub but many, it would be more likely if we had many collisions. The only difference is that we only use NT Server/Workstation machines. Well I know you don't like what I wrote in my last paragraph and I know I will again get a very aggressive answer and I think at the end I will someday switch to other cards. Like many people. I think that your aggressive way to answer questions is another problem. Why do you think you don't get many bug reports or people switching to other hardware? If both machines are sitting idle (not transmitting any data) and you just suddenly set the LoseNT host to full duplex, the FreeBSD machine isn't going to just say Hey! The LoseNT host changed modes! I better crash now! There must be more to it than that, but you're not going into any detail. I don't know what's going on in the background. Remember when I said I wanted *detailed* problem reports? Probably my english is too bad because I think saying After switching my NT machine to FullDuplex my FreeBSD server resets immidiately is a detailed bug report. Or should I say it like this: I switched my NT machine to FullDuplex and in the same second my FreeBSD Server shows a black screen and then I see the bios-output of my graphic card. After that I see the normal BIOS output and then the computer reboots my FreeBSD. This is why. How do we know there isn't some really explicit panic message on the console that's screaming: I crashed because of the following reason: foo? Maybe there's a message like that there, but we'll never know unless you tell us! I would have told you any error messages. I think everybody would. And you still haven't explained what you meant about the LoseNT machine crashing before. As I said in an earlier mail: If there are too many collisions my NT server crashes. Sometimes it doesn't crash but I can't send any data over the net either. I think it has something to do with the TCP/IP protocol because I then can't ping the NT machine nor the FreeBSD server. I have to reboot NT and everything works fine again. I can easily reproduce this error. Even with another NT machine which shows the same problem. If I don't transfer much data on the net, like reading html-pages from my FreeBSD server, or listening to an mp3 file (via samba), I don't get any collisions and the NT machine doesn't crash. Well this bug report is probably not detailed enough for you, but that's what i experience and I just tell you what i see. If you tell me what EXACTLY i shall look for, I'll do. Alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: xl driver for 3Com
I don't think that so many collisions are normal! I think there is a problem, because at work we nearly only use 3COM 100 Mbit cards and don't have much collisions. Even under high load! Collisions on half-duplex Ethernet are *normal*. Get used to it. Collisions is the standard flow control mechanism for half-duplex Ethernet. The amount of collisions you get depend on the cards used, the amount of traffic, and several other things. The amount of collisions is also not very interesting - the amount of *traffic* is. If you connect two hosts to a hub and run ttcp, to push a lot of traffic between them, you're very likely to get a 50% collision rate - with only two hosts. This is because *every* ack collides with a normal full sized packet. This is also perfectly fine and healthy. What you want to watch out for, is: - Late collisions (these are *not* normal) - Collisions when you think that the link is in full duplex mode. Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: xl driver for 3Com
Hi, Collisions on half-duplex Ethernet are *normal*. Get used to it. Collisions is the standard flow control mechanism for half-duplex Ethernet. The amount of collisions you get depend on the cards used, the amount of traffic, and several other things. The amount of collisions is also not very interesting - the amount of *traffic* is. Well as i described in a previous mail to Bill Paul, i tried to transfer two times 30MB of data via samba: At first I tried my FreeBSD machine and I got about 800-900 collisions. Second I booted on the same machine linux and I only got 4 (!) collisions. Bill Paul said to me that the FreeBSD TCP/IP is probably much faster. Well I'm sure that he is right, but from my point of view it didn't take longer to tranfer the files with linux. Anyway, i promised Bill Paul to measure exact values. Then we will see. I have no problem with thousands or millions of collissions, as long as they don't crash my computer. I just want a running system. And as my NT machine didn't crash on transfering a huge amount of data from a linux-server I have to think that this is a bug in something FreeBSD related. The only difference I could see between the two configurations were the collissions and as somebody on the list said there were problems with the xl driver under high load i wrote a letter to Bill Paul. I think I will simply switch to another card. Someone on the list said that their customer didn't have any problems after switching to intel cards. I don't want to switch back to linux again, because FreeBSD is much smoother. If you connect two hosts to a hub and run ttcp, to push a lot of traffic between them, you're very likely to get a 50% collision rate - with only two hosts. This is because *every* ack collides with a normal full sized packet. This is also perfectly fine and healthy. What you want to watch out for, is: - Late collisions (these are *not* normal) - Collisions when you think that the link is in full duplex mode. I will do further investigation to get more detailed infos. Unfotunately I'm very busy at the moment but I'll post more information as soon i get some results. Alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
Bill Paul writes: 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. This whole argument strikes me as a good wake up call for all of us. It really is important to make sure that problems with software are reported and that those reports are framed in a useful manner, because that is the only way that software gets improved. I'm sometimes guilty of not bothering to report bugs that I can easily work around, even though I hate it when people who use my software do the same. I'm re-motivated now to make the effort to contribute meaningful reports whenever I find bugs. As an aside, my experience with the xl driver (ever since I added it in to 2.2.7) has been completely positive, so I can't help with fixing any possible problems there. As for Dennis, he's just not worth responding to. He has a bad reputation as a total waste of space with an attitude problem as big as Texas. Just ignore him. -- Greg Black -- g...@acm.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: xl driver for 3Com
Hi, -Original Message- From: Greg Black [mailto:g...@acm.org] Sent: Dienstag, 1. Juni 1999 05:21 To: Bill Paul Cc: hack...@freebsd.org Subject: Re: xl driver for 3Com This whole argument strikes me as a good wake up call for all of us. It really is important to make sure that problems with software are reported and that those reports are framed in a useful manner, because that is the only way that software gets improved. I'm sometimes guilty of not bothering to report bugs that I can easily work around, even though I hate it when people who use my software do the same. I'm re-motivated now to make the effort to contribute meaningful reports whenever I find bugs. I think you're absolutely right but consider normal users like me. I try to provider as many information as I can, but for developpers this isn't enough. Instead of saying: Provide information!. You should ask detailed questions. As for Dennis, he's just not worth responding to. He has a bad reputation as a total waste of space with an attitude problem as big as Texas. Just ignore him. Well this, I think, is the wrong way. You expect people to know as much as you. I think you can rewrite code on the fly, but many people can't and they need help from hackers like you. There are so many FreeBSD-Hackers who are whining that Linux has so many users and FreeBSD hasn't. If people don't get support because people like you are ignoring them, they won't switch to FreeBSD even if it is much better. Alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
On Tue, 01 Jun 1999 10:31:21 +0200, Alexander Maret wrote: There are so many FreeBSD-Hackers who are whining that Linux has so many users and FreeBSD hasn't. No there are not. There are many FreeBSD enthusiasts who are whining that Linux has so many users and FreeBSD hasn't. FreeBSD _developers_ seem to be more concerned with producing a rock-solid operating system than producing a popular operating system. That is why most of the folks working on FreeBSD are more interested in meaningful problem reports than arm-waving fanatics. If there's a choice between keeping happy 100 people who don't know what's going on, or working with 10 people who do, most folks are going to choose to ignore the 100 for the sake of the 10. Not because they despise people who don't know what's going on, but because they can get good results out of people who do. This is natural and healthy given the objective of the FreeBSD project, which has never been to take over the world. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: xl driver for 3Com
Hi, -Original Message- From: Sheldon Hearn [mailto:sheld...@uunet.co.za] Sent: Dienstag, 1. Juni 1999 10:45 To: Alexander Maret Cc: hack...@freebsd.org Subject: Re: xl driver for 3Com FreeBSD _developers_ seem to be more concerned with producing a rock-solid operating system than producing a popular operating system. That is why most of the folks working on FreeBSD are more interested in meaningful problem reports than arm-waving fanatics. Sure, everybody likes the easy way. If there's a choice between keeping happy 100 people who don't know what's going on, or working with 10 people who do, most folks are going to choose to ignore the 100 for the sake of the 10. Not because they despise people who don't know what's going on, but because they can get good results out of people who do. Sure you can get better results working with 10 people who do know what's going on but if there are possible bugs and you just ignore the 100 people and say they're idiots who can't post real bug reports and who can't configure their system you won't get a rock-stable os. Even if 99% of the bug reports are configuration errors you can't ignore the 1%. Otherwise you won't get FreeBSD rock-stable. You have to deal with every user and ignoring people is no solution. Alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: xl driver for 3Com
This comparison with Linux is completely off. The number of knowledgable people working on USB for example is equivalent to the ones in FreeBSD. Most of the people talking on linux-usb are talkers not do-ers. FreeBSD developers do things in their spare time and they want other people to respect that. They want to see some investment from the other side as well to make it worthwhile. And if that trade off is not what you want, there are companies out there that solve problems for money (http://www.freebsd.org). Skipping to another card is short-term thinking. You assume that without your participation a new driver will be developed for another card, or another operating system will provide you with services. Who is 'paying' for that development then? Cheers, Nick Well this, I think, is the wrong way. You expect people to know as much as you. I think you can rewrite code on the fly, but many people can't and they need help from hackers like you. There are so many FreeBSD-Hackers who are whining that Linux has so many users and FreeBSD hasn't. If people don't get support because people like you are ignoring them, they won't switch to FreeBSD even if it is much better. Alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: xl driver for 3Com
Hi, -Original Message- From: Nick Hibma [mailto:nick.hi...@jrc.it] Sent: Dienstag, 1. Juni 1999 11:01 To: Alexander Maret Cc: FreeBSD hackers mailing list Subject: RE: xl driver for 3Com This comparison with Linux is completely off. The number of knowledgable people working on USB for example is equivalent to the ones in FreeBSD. What do you want to tell me with this sentence? Don't you like to be compared with linux? Well, if the same configuration runs on linux and not on a FreeBSD system then it can be a configuration error or a bug. Well if there are difference people always will compare. I compared those system to show that it can't be a hardware error because it runs with other systems. FreeBSD developers do things in their spare time and they want other people to respect that. They want to see some investment from the other side as well to make it worthwhile. And if that trade off is not what you want, there are companies out there that solve problems for money (http://www.freebsd.org). Well what do you want then? You're on the one hand whining that people don't post bug reports and on the other hand you say: Go away and ask other people. I didn't want configuration support but wanted to show that there is an ERROR!!! Skipping to another card is short-term thinking. You assume that without your participation a new driver will be developed for another card, or another operating system will provide you with services. You're wrong! I tried to participate but everybody just told me that I'm an idiot. Well perhaps they're right but if nobody wants to hear my bug report then I'll use another card. A card which driver has been better tested and where gifted programmers did the bug reports. Alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: xl driver for 3Com
FreeBSD developers do things in their spare time and they want people to respect that. They want to see some investment from the other side as well to make it worthwhile. And if that trade off is not what you want, there are companies out there that solve problems for money (http://www.freebsd.org). Well what do you want then? You're on the one hand whining that people don't post bug reports and on the other hand you say: Go away and ask other people. I didn't want configuration support but wanted to show that there is an ERROR!!! The discussion started with a remark about the fact that 3Com cards have problems under load, without a backing of that statement. That is the thing that made people trip over. It is a statement that is not the least helpful for anyone on the hackers mailing list and will not trigger help from anyone, apart from responses from people being frustrated about not being able to help (sounds silly but it is true, their puppy is being attacked without them being able to respond). You're wrong! I tried to participate but everybody just told me that I'm an idiot. Well perhaps they're right but if nobody wants to hear my bug report then I'll use another card. A card which driver has been better tested and where gifted programmers did the bug reports. You think along the lines of least resistance for solving your problems, while developers think along the lines of highest resistance to get bugs sorted out. Added to that was quite a bit of (justifiable) frustration from Bill P. side. And I don't think people call you an idiot and if they did, they are wrong. They are however entitled to express their opinion in a for them suitable way and should be read with their background and a context, you might not be fully aware of, in mind. Do not mistake this for people being angry at you. If you are able to read emotions from an e-mail accurately, you have a very special gift. Maybe we should revert to posting patches. They are easier to read. Nick. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: xl driver for 3Com
Hi, -Original Message- From: Nick Hibma [mailto:nick.hi...@jrc.it] Sent: Dienstag, 1. Juni 1999 11:58 To: Alexander Maret Cc: 'hack...@freebsd.org' Subject: RE: xl driver for 3Com The discussion started with a remark about the fact that 3Com cards have problems under load, without a backing of that statement. That is the thing that made people trip over. It is a statement that is not the least helpful for anyone on the hackers mailing list and will not trigger help from anyone, apart from responses from people being frustrated about not being able to help (sounds silly but it is true, their puppy is being attacked without them being able to respond). Yes, I read this remark and then decided to write to the developer because I had such a problem. I tried to post as many information as I could. Well it was not enough for Bill, but instead everyone just saying: Provide information people should ask questions. You will only exactly get what you want if you ask exact questions. Alex. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: xl driver for 3Com
Yes, I read this remark and then decided to write to the developer because I had such a problem. I tried to post as many information as I could. Well it was not enough for Bill, but instead everyone just saying: Provide information people should ask questions. You will only exactly get what you want if you ask exact questions. True. But you do have to know what the problem actually is when trying to ask questions. But let's get back to solving problems. Using two machines running 2.2.6 with Bill Paul's latest drivers for 2.2.x I've been able to make the machine go strange. It looks like it can't find DNS over the XL interface anymore (long timeouts on TAB in bash). The problem showed with ping -f from each machine to the other and a tcpblast with a packet size of 32768 and 10 packets (I will send the patch for tcpblast if the problem is reproducable). I don't know whether the problem is the packet size, but all of a sudden even the ping -f went down from 100kb a second to 4kb and the tcpblast was terminated. I also do not knw which machine actually went down (whether it was the one sending or receiving from tcpblast). I'll rig up two 3.2 machines this afternoon and see if I can reproduce the problem. If anyone has better suggestions on which programs to run to reproduce the problem, let me know. tcpblast was a first guess. Cheers, Nick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: xl driver for 3Com
Alexander Maret writes: Hi, -Original Message- From: Sheldon Hearn [mailto:sheld...@uunet.co.za] Sent: Dienstag, 1. Juni 1999 10:45 To: Alexander Maret Cc: hack...@freebsd.org Subject: Re: xl driver for 3Com FreeBSD _developers_ seem to be more concerned with producing a rock-solid operating system than producing a popular operating system. That is why most of the folks working on FreeBSD are more interested in meaningful problem reports than arm-waving fanatics. Sure, everybody likes the easy way. If there's a choice between keeping happy 100 people who don't know what's going on, or working with 10 people who do, most folks are going to choose to ignore the 100 for the sake of the 10. Not because they despise people who don't know what's going on, but because they can get good results out of people who do. Sure you can get better results working with 10 people who do know what's going on but if there are possible bugs and you just ignore the 100 people and say they're idiots who can't post real bug reports and who can't configure their system you won't get a rock-stable os. Even if 99% of the bug reports are configuration errors you can't ignore the 1%. Otherwise you won't get FreeBSD rock-stable. You have to deal with every user and ignoring people is no solution. Alex Well, I've been subscribed to freebsd-questions for the last couple of weeks to see how things are going in the user community, and, I must say, I do not remember seeing your name attached to any answers to questions over there. So the points are raised: If the 1% is so important, why do you not help them out in the forum where they are most prevalent? Are you not ignoring them? Bud Dodson -- M. L. Dodsonbdod...@scms.utmb.edu 409-772-2178FAX: 409-772-1790 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
On Tue, 1 Jun 1999 10:09:59 +0200 Alexander Maret ma...@axis.de wrote: At first I tried my FreeBSD machine and I got about 800-900 collisions. Second I booted on the same machine linux and I only got 4 (!) collisions. It's also possible that Linux isn't counting the collisions properly. I have no problem with thousands or millions of collissions, as long as they don't crash my computer. I just want a running system. Collisions don't cause your system to crash. If this is happening, something else is at fault (though that something else may be an unrelated problem in the Ethernet driver). -- Jason R. Thorpe thor...@nas.nasa.gov To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
Of all the gin joints in all the towns in all the world, Alexander Maret had to walk into mine and say: Hi, Well maybe FreeBSD is transmitting packets much faster than Linux. :) You still haven't actually measured the transfer speed, so there's no way for us to know. Well, I'll do and report the results to you. Actually, there's another difference between the behavior of the FreeBSD and Linux drivers that could affect this. There may be a similar difference between the FreeBSD and LoseNT drivers too, but I'm only vaguely familiar with how LoseNT (or rather, NDIS miniport) drivers work so I can't be sure about that. Basically, the driver has one particular entry point for initiating packet transmission. In Linux, this entry point gets handed a single packet (stored in an skbuff) and a pointer to the device structure for that particular driver instance. In FreeBSD, the start routine gets handed a pointer to the ifnet structure for the interface (which is associated with the driver). The ifnet structure in turn contains the send queue which may have several packets queued for transmission in the form of mbufs (the maximum number depends on the size of ifq_maxlen, which the driver can set at initialization time). The difference is that in Linux, the driver sets up a single DMA/transmit sequence at a time, because the transmit routine only gets access to one packet at a time. In FreeBSD, the driver has access to the entire send queue, where there may be several packets waiting. The driver can then handle the send queue as it sees fit: it can pop the first packet off the queue and transmit it, then wait for it to complete before moving on to the next packet, or it can pop a whole series of packets off the send queue and set up a large DMA transfer where all of the packets will get transfered at once, rather than one at a time. (The driver may still program the NIC to signal successful transmission of each frame in the transfer just to make sure things are working right, but it may also choose just to have the NIC acknowledge the last packet in the transfer in order to reduce the number of interrupts. The xl driver requests an interrupt only for the last frame in a DMA transfer.) The FreeBSD driver also sets the transmit threshold for best performance. The transmit start threshold specifies how many bytes should be transfered to the NIC's memory before it will begin putting the data on the wire. The idea is that transfer of data from the host to the NIC can proceed simultaneously with transmission of data from the NIC to the wire: as new data arrives in the NIC, it gets dumped onto the network as soon as possible. Note however that this only works well if the host can keep up. With slower systems, you may see transmit underruns where the NIC wants to transmit but the data isn't ready yet. In this case, the driver will increase the transmit start threshold and generate a message telling what happened. Eventually, the threshold will be increased enough that the transmit underrun condition will not appear anymore. This means that it's possible for the FreeBSD driver to transmit a whole bunch of packets at once with very little time in between. If there's another host transmitting back at the same time, this also means that you're more likely to see collisions. However it also means that you get very fast transmissions, which is supposed to be a good thing. Can you throttle back the xl driver? Well, yes, if you want. There are two things you can do: - Use a different default for the transmit start threshold. In xl_init(), the driver initializes sc-xl_tx_thresh to XL_MIN_FRAMELEN, which is 60. You can change this to 120 or 512, or even 1536 if you want to disable the threshold entirely and have the NIC wait until the whole packet has been DMAed into its memory before it starts a transmission. - Make xl_start() only queue one packet at a time. This unforunately requires some code changes (not big ones, but it's more than just changing a setting somewhere). Grrr. I'm sorry, but I really don't think you're putting the pieces together correctly. Setting the NT machine to full duplex should have absolutely no effect on the FreeBSD host. It will completely screw up performance since the LoseNT host will then no longer be set to match the hub, but that's another problem. I strongly suspect that you're not making the proper observations when your problem manifests and just leaping to the conclusion that setting the LoseNT host to full duplex crashes the FreeBSD host. I just tell you what i experienced. Well, it's suspicious. It gives the impression that setting the LoseNT host to full duplex mode somehow angered the computer gods, prompting them to make your FreeBSD host spontaneously reboot. Also, there might be more to it. For example, if you were running the X Window system on the console at the time, then there may have been a panic message printed which you
Re: xl driver for 3Com
At 08:00 AM 6/1/99 -0700, you wrote: On Tue, 1 Jun 1999 10:09:59 +0200 Alexander Maret ma...@axis.de wrote: At first I tried my FreeBSD machine and I got about 800-900 collisions. Second I booted on the same machine linux and I only got 4 (!) collisions. It's also possible that Linux isn't counting the collisions properly. I have no problem with thousands or millions of collissions, as long as they don't crash my computer. I just want a running system. Collisions don't cause your system to crash. If this is happening, something else is at fault (though that something else may be an unrelated problem in the Ethernet driver). If your nic driver chains packets (such that there is no time in between) you will see good throughput from the box but your overall network performance will suffer. A PCI card with continueous traffic can completely hog your lan (particularly at 10Mb/s)...which can cause a lot more collisions on your network as other devices will not have access until the hog is finished sending. For Fairness gaps in between frames are better as you approach capacity of your wire. Dennis To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
At 08:06 PM 5/30/99 -0700, you wrote: It is kind of interesting that now the shoe is on the other foot... A few months ago I purchased some sync cards from ET, and had some (and am still having) trouble getting them to work consistently. When I emailed their support dept for help, I got a few curt non-helpful replies, then a message about how if I didn't understand every nuance of HDLC, and couldn't read the debugging output of his cards/software, then I was (my interpratation, not his words exactly) not worth of his effort, nor his company's products. You had the cards connected back to back, which is not a normal configuratoin. I have offered access to the boxes for the trivially repeatable problem I am having, in order so that he can improve his product, but the answer so far is Try a new version of the software. The shotgun approach to tech support. Because your problem has been fixed, I believe. Your constantly email and simply said it doesnt work...if you do it correctly it works, and I cannot debug a back-to-back config for you. It is no wonder that he does not invest effort in helping the 3com driver work better, he is unwilling to work with a customer with a significant dollar amount invested in his boards make *his* product better, why would he be worried about improving others product, he has little interest in improving his own. We have thousands of boards installedmaking them work back to back in a non-standard configuration does not make the product *better*, particularly when working with someone who cant provide useful info on *why* it doesnt work. I wish I could stop what I was doing every time someone had a problem, but I dont have that kind of time. Which is too bad, because when it works, it (the ET board) works just great. When it doesn't, don't ask ET for help. What you get is a lot of talking down, what you don't get is real help. I told you that we fixed something recently that sounded like the problem you were having...did you try it, or is it too much trouble? I cant debug old versions of software. If you are not using the latest version then you MUST upgrade to get proper support. We cant spend hours debugging problems that have already been fixed. It took you 2 weeks to find provide any useful information. When someone calls and says it doesnt work there is not much I can do. Next time try calling on the phone when you are in front of the machine instead of emailing snippits of useless info. Of course now that you've publically badmouthed us Im sure your requests well get very high priority :-) Dennis To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
At 02:50 PM 5/30/99 -0700, you wrote: I have no stake in 3com cards (they are problematic in LINUX as well)...maybe the cards are flawed? Its not my problem. It *is* your problem. Supposing you can't get Intel cards anymore. Then what're you going to do. Use something else that works. If none of them work then FreeBSD is no longer a viable option. This is the core fallacy; you should restate this as: If none of them work, then FreeBSD is no longer a viable option because it will require me to do some work to help fix them. I'm sorry; the FreeBSD Project is dedicated to developing operating system code, not wiping your ass. You've received abundant offers of assistance requiring no more than minimal effort on your part, and turned them all down. This kind of selfish laziness is something we can all do without. hey mike, why dont you try to pay attention. This was a CUSTOMER who was UNWILLING to donate their network to the freebsd project. Get it? I dont have 3com cards, I dont like 3com. I just reported that someone had a problem. I already work 70 hours a week pal, so dont give me this lazy bullshit. Im supposed to fix the 3com driver and the dec driver and the nfs code and all the other things wrong with freebsd, right? Why doesnt someone who ACTUALLY USES 3com cards donate their time? If noone is having a problem, then why worry? So if you are saying that we shouldnt report problems if we are not willing to donate our time to fix them then so be it. If you think that every time one of my customers has some problem with something in FreeBSD I'm going to spend days trying to fix it, you have been out in the outback way too long. Im not on the core team, its not my driver, and I couldnt give a rats ass if the 3com driver ever works...next time I'll just quietly tell the customer and let every other poor sole who uses 3com cards find out for themselves. What a seflish guy I am. DB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
Dennis wrote: For Fairness gaps in between frames are better as you approach capacity of your wire. Isn't there some ethernet requirement (implemented on the NIC) that a transmitter holds off the wire a little to give other NICs enough time to notice there's nothing being transmitted? The sequence of events would be something like: NIC1NIC2time | v start xmit host queues next packet xmit finishes start back-to-back delay sense idle wire start xmit sense access from NIC2 back-to-back delay ends wait for wire idle xmit finishes sense idle start xmit Or did I just fall asleep reading the spec and dream this. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
Dennis wrote: For Fairness gaps in between frames are better as you approach capacity of your wire. Isn't there some ethernet requirement (implemented on the NIC) that a transmitter holds off the wire a little to give other NICs enough time to notice there's nothing being transmitted? The sequence of events would be something like: NIC1 NIC2time | v start xmit host queues next packet xmit finishes start back-to-back delay sense idle wire start xmit sense access from NIC2 back-to-back delay ends wait for wire idle xmit finishes sense idle start xmit No, only when there is a collision, both sides then wait a random amount of time before trying again. Marc. Marc van Kempen BowTie Technology Email: m...@bowtie.nlWWW Databases tel. +31 40 2 43 20 65 fax. +31 40 2 44 21 86 http://www.bowtie.nl To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
If your nic driver chains packets (such that there is no time in between) you will see good throughput from the box but your overall network performance will suffer. A PCI card with continueous traffic can completely hog your lan (particularly at 10Mb/s)...which can cause a lot more collisions on your network as other devices will not have access until the hog is finished sending. For Fairness gaps in between frames are better as you approach capacity of your wire. Dennis the interframce gap will allow other hosts to contend for the wire. the ethernet capture effect decreases as the number of hosts on the segment increases. the interpacket gap is 9.6uS (or 96 bit times). an ethernet card listens to the wire before transmitting a card that is not able to transmit because the wire is busy will begin transmitting as soon as the wire goes quiet. the max length of an ethernet is 46 bit times. so a waiting card will alaways get first crack at the wire. capture effect is due to stations colliding in trying to access the wire. those that dont collide, are immune to the capture effect and get the wire first. http://wwwhost.ots.utexas.edu/ethernet/papers.html jmb To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
At 11:03 AM 6/1/99 -0700, you wrote: If your nic driver chains packets (such that there is no time in between) you will see good throughput from the box but your overall network performance will suffer. A PCI card with continueous traffic can completely hog your lan (particularly at 10Mb/s)...which can cause a lot more collisions on your network as other devices will not have access until the hog is finished sending. For Fairness gaps in between frames are better as you approach capacity of your wire. Dennis the interframce gap will allow other hosts to contend for the wire. the ethernet capture effect decreases as the number of hosts on the segment increases. the interpacket gap is 9.6uS (or 96 bit times). an ethernet card listens to the wire before transmitting a card that is not able to transmit because the wire is busy will begin transmitting as soon as the wire goes quiet. the max length of an ethernet is 46 bit times. so a waiting card will alaways get first crack at the wire. capture effect is due to stations colliding in trying to access the wire. those that dont collide, are immune to the capture effect and get the wire first. and if you have 2 cards waiting? or 3? or 10? Im not sure why, but with certain PCI drivers there are a lot more collisions. Dennis To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
On Tue, 1 Jun 1999, Dennis wrote: If your nic driver chains packets (such that there is no time in between) you will see good throughput from the box but your overall network performance will suffer. A PCI card with continueous traffic can completely hog your lan (particularly at 10Mb/s)...which can cause a lot more collisions on your network as other devices will not have access until the hog is finished sending. For Fairness gaps in between frames are better as you approach capacity of your wire. The ethernet spec defines the acceptable inter-frame gap. Some cards have been known to use the minimum or less in order to 'go faster'. I believe that this is tunable on some cards. (LANCE comes to mind.) If the card isn't using the correct IFG and doesn't provide a knob to fix it, then there isn't much we can do when the card captures the wire. Enabeling interrupt per packet isn't the answer either. If you're running an unswitched LAN and use rogue cards you aren't in a position to fuss when they do bad things. If you cared about speed you'd use a switch in full duplex mode. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | win...@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
Dennis wrote: At 08:00 AM 6/1/99 -0700, you wrote: On Tue, 1 Jun 1999 10:09:59 +0200 Alexander Maret ma...@axis.de wrote: At first I tried my FreeBSD machine and I got about 800-900 collisions. Second I booted on the same machine linux and I only got 4 (!) collisions. It's also possible that Linux isn't counting the collisions properly. I have no problem with thousands or millions of collissions, as long as they don't crash my computer. I just want a running system. Collisions don't cause your system to crash. If this is happening, something else is at fault (though that something else may be an unrelated problem in the Ethernet driver). If your nic driver chains packets (such that there is no time in between) you will see good throughput from the box but your overall network performance will suffer. Overall network performance will be much greater until the collision rate raises high enough to lower it. The only way to determine this is to try it, unless you have some pretty sophisticated network modelling tools. A PCI card with continueous traffic can completely hog your lan (particularly at 10Mb/s)... Even at 100Mb/s with good cards and moderatly fast computers. Hogging your LAN is spelled the same as getting 100% throughput around here, and is considered a GOOD thing. I fail to see how obtaining 200Mb/s (full-duplex) throughput on a $50 lan adapter is a bad thing. which can cause a lot more collisions on your network as other devices will not have access until the hog is finished sending. For Fairness gaps in between frames are better as you approach capacity of your wire. Or just do yourself a favor and buy a good switch, which avoids the collision problems neatly. Ethernet doesn't have to be a shared media system. I can help if you want suggestions. ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: xl driver for 3Com
The discussion started with a remark about the fact that 3Com cards have problems under load, without a backing of that statement. That is the thing that made people trip over. It is a statement that is not the least helpful for anyone on the hackers mailing list and will not trigger help from anyone, apart from responses from people being frustrated about not being able to help (sounds silly but it is true, their puppy is being attacked without them being able to respond). If it had no backing then how could it be a fact? replacing the cards with intels and having the problem go away is backing. It may not be *useful*, but it is backing. Dennis To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: xl driver for 3Com
The discussion started with a remark about the fact that 3Com cards have problems under load, without a backing of that statement. That is the thing that made people trip over. It is a statement that is not the least helpful for anyone on the hackers mailing list and will not trigger help from anyone, apart from responses from people being frustrated about not being able to help (sounds silly but it is true, their puppy is being attacked without them being able to respond). You're wrong! I tried to participate but everybody just told me that I'm an idiot. Well perhaps they're right but if nobody wants to hear my bug report then I'll use another card. A card which driver has been better tested and where gifted programmers did the bug reports. You think along the lines of least resistance for solving your problems, while developers think along the lines of highest resistance to get bugs sorted out. Added to that was quite a bit of (justifiable) frustration from Bill P. side. And I don't think people call you an idiot and if they did, they are wrong. They are however entitled to express their opinion in a for them suitable way and should be read with their background and a context, you might not be fully aware of, in mind. Do not mistake this for people being angry at you. If you are able to read emotions from an e-mail accurately, you have a very special gift. A good developer knows that not everyone that uses his product is technically capable to help out when there is a problem. Sometimes you cant even get people to explain the basic symptoms. A developers job is to develop a test bed to recreate problems based on what users tell him. You can't expect users to spend their time debugging your code. If you get one your lucky...you cant *expect* people to work with you...people have things to do. Why should they struggle with one $58. card when for $49. they can get a different one that works? Thats common sense. Until you find someone with a truckload of 3com cards that doesnt want to have to toss them all you have to find the problems yourself. Most of my customers are internet service providers...if their net is down for 5 minutes the phones start ringing off the wall. They need something that works NOW. Bill, when you get out the last bug you can stand on your desk and beat your chest and everyone will applaud you. Until then, you have a headache. Dont be pissed at me...I have more headaches thnn I have heads without worrying about yours too. I find that a nice cold Bass Ale is soothing when Im working on a killer bug. Have a beer, watch the Knicks beat up on the Pacers. Very relaxing. Dennis To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
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: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@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 majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
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. Leaving busy networks etc. aside, this is purely a characteristic of the card in question - it's just very 'agressive' on the wire and doesn't like to back off. I wouldn't worry about it. - ad To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
Of all the gin joints in all the towns in all the world, Alexander Maret had to walk into mine and say: Hmm, I'm no expert and this all sounds reasonable to me, but there are things I haven't mentioned yet: Grrr. What were you waiting for. You should have mentioned them to start with. When I boot linux on my FreeBSD server and I transfer the same 30MB of Data via Samba, I only get 4 (!) collisions (HalfDuplex). Well maybe FreeBSD is transmitting packets much faster than Linux. :) You still haven't actually measured the transfer speed, so there's no way for us to know. The collisions are measured with the 3COM NIC-Doctor. I don't know if I can trust the output of NIC Doctor but I'm (as a newbie) highly alerted by the difference of those two values. Anyway - I will try what you told me and look at the leds and at the netstat output. I also would like to know how I can set up my FreeBSD system to support Full Duplex. Grrr. This tells me that you may not understand what full duplex really means. You're not allowed to fiddle with the full-duplex/half-duplex setting like it's some performance knob that you can crank up to make things work better. If all you have is a hub, then the hub only supports half duplex. You can't set the machines to full duplex if the hub is only half duplex. You'll get rotten performance. On the other hand, if you have a *switch* -- which is *NOT* the same thing as a hub! -- and the switch ports support full duplex operation (which most do), *then* you can set the hosts for full duplex. Usually though, switches support NWAY autonegotiation, which means the NICs should autodetect the fact that the switch supports full duplex and the switch port and the NIC will both agree to use full duplex automatically. You can also use full duplex if you wire the machines back to back with a crossover cable. As to how you set the interface to full duplex, there are man pages to read which will tell you that. Naturally, being a newbie, you feel you have a god given right to ignore the man pages and go rummaging around with your web browser chewing up bandwidth instead of reading the instructions right under your nose. If you read the ifconfig(8) man page and the xl(4) man page, you would learn that the right way to do it is: # ifconfig xl0 media 100baseTX mediaopt full-duplex Another interesting thing: If i switch the my NT client to FullDuplex and FreeBSD is in HalfDuplex mode then my FreeBSD server resets immidiately. Grrr. I'm sorry, but I really don't think you're putting the pieces together correctly. Setting the NT machine to full duplex should have absolutely no effect on the FreeBSD host. It will completely screw up performance since the LoseNT host will then no longer be set to match the hub, but that's another problem. I strongly suspect that you're not making the proper observations when your problem manifests and just leaping to the conclusion that setting the LoseNT host to full duplex crashes the FreeBSD host. I don't think that's true. If both machines are sitting idle (not transmitting any data) and you just suddenly set the LoseNT host to full duplex, the FreeBSD machine isn't going to just say Hey! The LoseNT host changed modes! I better crash now! There must be more to it than that, but you're not going into any detail. Remember when I said I wanted *detailed* problem reports? This is why. How do we know there isn't some really explicit panic message on the console that's screaming: I crashed because of the following reason: foo? Maybe there's a message like that there, but we'll never know unless you tell us! So don't tell me it resets immediately. Tell me *EXACTLY* what appears on the console (or if!) it crashes, word for word. Not your interpretation of what it says: *EXACTLY* what it says. And you still haven't explained what you meant about the LoseNT machine crashing before. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@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 majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
At 05:59 PM 5/29/99 -0400, you wrote: Of all the gin joints in all the towns in all the world, Dennis had to walk into mine and say: Then *FIND THEM OUT*! Replacing the cards does not fix the problem! How is anybody supposed to be able to help you if a) you never tell anybody about the trouble, b) you destroy the test configuration where the problem occurs, thereby assuring that nobody will be able to duplicate it again, and c) you don't even lift a finger to investigate! I dont want help, That's too bad because you really need it! I recommended Intel cards, the customer used 3coms because someone told them they were good cards, they had problems, and I said I told you so. Im just relaying the info..if I had REAL info as the what the problem was I would have told you, but commercial sites are not the place to be debugging problems. They are the *perfect* place to be debugging problems! Who do you think causes most of them!? And just what kind of information did you think you were relaying? Couldn't you be bothered to invest a few seconds to at least find out what version of FreeBSD they had? And how much are you going to pay them to have their people debug a problem that can be fixed by using another card? You academics crack me up. I have no stake in 3com cards (they are problematic in LINUX as well)...maybe the cards are flawed? Its not my problem. It *is* your problem. Supposing you can't get Intel cards anymore. Then what're you going to do. Use something else that works. If none of them work then FreeBSD is no longer a viable option. Not that I wouldnt like to help, but when I have a company president calling me to complain that the box is going down Im in no position to say stick with the 3com cards, they'll have them running soon. Its the way it is. No, that's not the way it is. You can't play musical hardware forever. Sooner or later you're going to run into a situation where you won't have another hardware option, and then your company president is going to find out just how useless you are and replace you. Yes you can. If intel stops producing cards them some other card will become the darling of Freebsd. All OSes have a few cards that are battle tested and lots of other ones that work ok if you dont try to do too much with them. It IS the way it is, and its the way its been with PC unices since the days of XENIX 286. Why is the DEC PCI driver so good in linux and so crappy in FreeBSD? Because they spend a LOT more time on it, and it is highly supported. Nobody cares about it in FreeBSD, when I complained that my -AC revision wouldnt probe on a 10mb/s network (it STILL doesnt work a year later), I switched to intel because noone seemed to care. They kept telling me to port Matt's netbsd driver. Why should I deal with that headache when I can just use something else? You need to find beta test sights (gee, columbia might be a good one, huh?) to do testing. Commercial sites are no place for such things. You just don't get it do you! In order to be able to fix a problem, you have to be able to duplicate it! I do this for a living, you think I dont get it? Some customers let me fix bugs when they have them, some are less patient. Until I get a customer who is willing to work with me, then it doesnt get fixed. I just fixed a problem last week that has been haunting me for months, because i FINALLY got someone to do a dump analysis rather than just whine about it. You have to have customers that are technically competent to work with. The 3com customer had a bridge set up between a $75,000 cisco with a T3 and over 2000 hosts. You cant ask them to take their network down because their ethernet card is locking up every few hours. Be real. I have tons of 3Coms here and they all work perfectly! If somebody has a problem with one, it's because they've put together a particular hardware and software configuration that triggers some pathological behavior. It's not fair then to expect somebody to be able to fix your problem i I didnt ask you to fix my problem, did I? The last problem I had I gave you the patch because my customer let me fix it and it was easy to find. This time they weren't patient and were ready to cancel the order. And they didnt know what they were doing. They needed a plug and play solution, which is why they bought my product in the first place. I used to recommend DEC cards, and now the driver sucks, so I dont. I recommend DEC or Intel in LINUX, because they work best. I dont care what they use, and Im not concerned about the 35 drivers that have problems under load. I cant be. I dont have time, and what's the difference? All cards have the same functionality. The difference is that not everybody has access to all hardware! The difference is that not everybody can afford all hardware! The difference is that all cards don't get manufactured forever! The difference is that if you can't be bothered to get off you ass and actually
Re: xl driver for 3Com
I have no stake in 3com cards (they are problematic in LINUX as well)...maybe the cards are flawed? Its not my problem. It *is* your problem. Supposing you can't get Intel cards anymore. Then what're you going to do. Use something else that works. If none of them work then FreeBSD is no longer a viable option. This is the core fallacy; you should restate this as: If none of them work, then FreeBSD is no longer a viable option because it will require me to do some work to help fix them. I'm sorry; the FreeBSD Project is dedicated to developing operating system code, not wiping your ass. You've received abundant offers of assistance requiring no more than minimal effort on your part, and turned them all down. This kind of selfish laziness is something we can all do without. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
It is kind of interesting that now the shoe is on the other foot... A few months ago I purchased some sync cards from ET, and had some (and am still having) trouble getting them to work consistently. When I emailed their support dept for help, I got a few curt non-helpful replies, then a message about how if I didn't understand every nuance of HDLC, and couldn't read the debugging output of his cards/software, then I was (my interpratation, not his words exactly) not worth of his effort, nor his company's products. I have offered access to the boxes for the trivially repeatable problem I am having, in order so that he can improve his product, but the answer so far is Try a new version of the software. The shotgun approach to tech support. It is no wonder that he does not invest effort in helping the 3com driver work better, he is unwilling to work with a customer with a significant dollar amount invested in his boards make *his* product better, why would he be worried about improving others product, he has little interest in improving his own. Which is too bad, because when it works, it (the ET board) works just great. When it doesn't, don't ask ET for help. What you get is a lot of talking down, what you don't get is real help. On Sun, 30 May 1999, Mike Smith wrote: I have no stake in 3com cards (they are problematic in LINUX as well)...maybe the cards are flawed? Its not my problem. It *is* your problem. Supposing you can't get Intel cards anymore. Then what're you going to do. Use something else that works. If none of them work then FreeBSD is no longer a viable option. This is the core fallacy; you should restate this as: If none of them work, then FreeBSD is no longer a viable option because it will require me to do some work to help fix them. I'm sorry; the FreeBSD Project is dedicated to developing operating system code, not wiping your ass. You've received abundant offers of assistance requiring no more than minimal effort on your part, and turned them all down. This kind of selfish laziness is something we can all do without. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
+[ Bill Paul ]- | | but I don't know the details. Yes! I like it! Instead of trying to help | people, I'll be maddeningly vague! I'll pretend to be helpful but stop | short of actually providing any useful information! Then everyone else Be careful Bill, or they'll make you a Business Analyst. -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | Milton ACN: 082 081 472 | M:+61 416 022 411 |72 Col .Sig PO Box 837 Indooroopilly QLD 4068|a...@theinternet.com.au|Specialist To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
wonderful! You know, I should use that myself! Hey Bill: my network crashed. Well, there's probably something you could do to fix that but I don't know the details. Yes! I like it! Instead of trying to help people, I'll be maddeningly vague! I'll pretend to be helpful but stop You have a very promising career as a consultant ahead of you, Bill. :-) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
At 1:40 am -0400 29/5/99, Bill Paul wrote: [...] Yes! I like it! Instead of trying to help people, I'll be maddeningly vague! I'll pretend to be helpful but stop short of actually providing any useful information! Then everyone else will go insane instead of me, society will collapse, and I can take over the world while everyone's distracted! Methinks someone's been reading too much Dilbert. -- Bob Bishop (0118) 977 4017 international code +44 118 r...@gid.co.ukfax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
Bill Paul wp...@skynet.ctr.columbia.edu writes: [...] Yes! I like it! Instead of trying to help people, I'll be maddeningly vague! I'll pretend to be helpful but stop short of actually providing any useful information! Then everyone else will go insane instead of me, society will collapse, and I can take over the world while everyone's distracted! Yes, Bill, we love you too :) DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
At 01:40 AM 5/29/99 -0400, you wrote: Of all the gin joints in all the towns in all the world, Dennis had to walk into mine and say: I dunno what it is, but we've had customers experiencing packet loss at high usage on 100Mb's nets...and the problem goes away when replacing them with intels. I dont know the details. Then *FIND THEM OUT*! Replacing the cards does not fix the problem! How is anybody supposed to be able to help you if a) you never tell anybody about the trouble, b) you destroy the test configuration where the problem occurs, thereby assuring that nobody will be able to duplicate it again, and c) you don't even lift a finger to investigate! I dont want help, I recommended Intel cards, the customer used 3coms because someone told them they were good cards, they had problems, and I said I told you so. Im just relaying the info..if I had REAL info as the what the problem was I would have told you, but commercial sites are not the place to be debugging problems. I have no stake in 3com cards (they are problematic in LINUX as well)...maybe the cards are flawed? Its not my problem. Not that I wouldnt like to help, but when I have a company president calling me to complain that the box is going down Im in no position to say stick with the 3com cards, they'll have them running soon. Its the way it is. You need to find beta test sights (gee, columbia might be a good one, huh?) to do testing. Commercial sites are no place for such things. I used to recommend DEC cards, and now the driver sucks, so I dont. I recommend DEC or Intel in LINUX, because they work best. I dont care what they use, and Im not concerned about the 35 drivers that have problems under load. I cant be. I dont have time, and what's the difference? All cards have the same functionality. This is ridiculous! People ask me to fix stuff, they expect the world! You ask them what's going on, they don't know the details! That's just wonderful! You know, I should use that myself! Hey Bill: my network crashed. Well, there's probably something you could do to fix that but I don't know the details. Yes! I like it! Instead of trying to help people, I'll be maddeningly vague! I'll pretend to be helpful but stop short of actually providing any useful information! Then everyone else will go insane instead of me, society will collapse, and I can take over the world while everyone's distracted! You know if they ever find a way to harness sarcasm as an energy source, you people are all going to owe me big. hey, you want to be famous, you gotta take some punches. When my drivers have bugs, I take it on the chin. Part of the developer experience. :-) Dennis Emerging Technologies, Inc. http://www.etinc.com ISA and PCI T1/T3/V35/HSSI Cards for FreeBSD and LINUX HSSI/T3 UNIX-based Routers Bandwidth Manager http://www.etinc.com/bwmgr.htm To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
Of all the gin joints in all the towns in all the world, Dennis had to walk into mine and say: Then *FIND THEM OUT*! Replacing the cards does not fix the problem! How is anybody supposed to be able to help you if a) you never tell anybody about the trouble, b) you destroy the test configuration where the problem occurs, thereby assuring that nobody will be able to duplicate it again, and c) you don't even lift a finger to investigate! I dont want help, That's too bad because you really need it! I recommended Intel cards, the customer used 3coms because someone told them they were good cards, they had problems, and I said I told you so. Im just relaying the info..if I had REAL info as the what the problem was I would have told you, but commercial sites are not the place to be debugging problems. They are the *perfect* place to be debugging problems! Who do you think causes most of them!? And just what kind of information did you think you were relaying? Couldn't you be bothered to invest a few seconds to at least find out what version of FreeBSD they had? I have no stake in 3com cards (they are problematic in LINUX as well)...maybe the cards are flawed? Its not my problem. It *is* your problem. Supposing you can't get Intel cards anymore. Then what're you going to do. Not that I wouldnt like to help, but when I have a company president calling me to complain that the box is going down Im in no position to say stick with the 3com cards, they'll have them running soon. Its the way it is. No, that's not the way it is. You can't play musical hardware forever. Sooner or later you're going to run into a situation where you won't have another hardware option, and then your company president is going to find out just how useless you are and replace you. You need to find beta test sights (gee, columbia might be a good one, huh?) to do testing. Commercial sites are no place for such things. You just don't get it do you! In order to be able to fix a problem, you have to be able to duplicate it! I have tons of 3Coms here and they all work perfectly! If somebody has a problem with one, it's because they've put together a particular hardware and software configuration that triggers some pathological behavior. It's not fair then to expect somebody to be able to fix your problem if you don't make even the tiniest effort to explain what kind of configuration you have! Just who the hell are these famous customers of yours? Didn't it occur to you suggest that they file a bug report so that maybe their problem could be fixed and save them from having to buy new cards? This would not take a huge amount of time or effort! I used to recommend DEC cards, and now the driver sucks, so I dont. I recommend DEC or Intel in LINUX, because they work best. I dont care what they use, and Im not concerned about the 35 drivers that have problems under load. I cant be. I dont have time, and what's the difference? All cards have the same functionality. The difference is that not everybody has access to all hardware! The difference is that not everybody can afford all hardware! The difference is that all cards don't get manufactured forever! The difference is that if you can't be bothered to get off you ass and actually report bugs properly and take some time to try testing a fix, pretty soon nobody will want to be bothered writing software for you anymore! hey, you want to be famous, you gotta take some punches. When my drivers have bugs, I take it on the chin. Part of the developer experience. :-) Don't you smiley at me! How would you feel if people just gradually stopped buying your products, and then one day you found out that it was was because of some silly little bug in your code that you could have fixed in fiv minutes if only somebody had cared enough to actually tell you about it? You'd be pretty pissed off, wouldn't you! More than that, your boss would be pretty pissed off too! So, tell me: just how many of you other people reading this have been having problems with 'drivers under load' and couldn't be bothered to actually report the problem? Hm? Well what're you waiting for?! Go on: speak up! Take two minutes of your precious time! I dare you! I double-dare you! No, I *triple*-dare you! Take your best shot! -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@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 majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
On Sat, 29 May 1999, Bill Paul wrote: :So, tell me: just how many of you other people reading this have been :having problems with 'drivers under load' and couldn't be bothered to :actually report the problem? Hm? Well what're you waiting for?! Go on: :speak up! Take two minutes of your precious time! I dare you! I :double-dare you! No, I *triple*-dare you! Take your best shot! No no no no no. You gotta 'triple -dog- dare' them. Jamie Bowden -- If we've got to fight over grep, sign me up. But boggle can go. -Ted Faber (on Hasbro's request for removal of /usr/games/boggle) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
At 02:58 PM 5/28/99 +0200, you wrote: Hi there hackers. I need to hack the driver file if_xl.c to do the following : - Detect the first 3Com card normally. - All cards hereafter must only be able to receive packets, not transmit them. Does anybody know how i can achieve this by changes in the file if_xl.c Even if you could point me to a specific subroutine it would be appreciated. Thanyou in advance Note that this card/driver seems to have serious problems under heavy load. Just so you know. Dennis To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
At 02:58 PM 5/28/99 +0200, you wrote: Hi there hackers. I need to hack the driver file if_xl.c to do the following : - Detect the first 3Com card normally. - All cards hereafter must only be able to receive packets, not transmit them. looks like the typical ipfw thing, rather than hacking the driver! (well, there are ARP, but can be done ...) cheers luigi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
At 02:58 PM 5/28/99 +0200, you wrote: Hi there hackers. I need to hack the driver file if_xl.c to do the following : - Detect the first 3Com card normally. - All cards hereafter must only be able to receive packets, not transmit them. Does anybody know how i can achieve this by changes in the file if_xl.c Even if you could point me to a specific subroutine it would be appreciated. Thanyou in advance Note that this card/driver seems to have serious problems under heavy load. Just so you know. It does? Have you spoken to Bill Paul about it? -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
At 09:29 AM 5/28/99 -0700, you wrote: At 02:58 PM 5/28/99 +0200, you wrote: Hi there hackers. I need to hack the driver file if_xl.c to do the following : - Detect the first 3Com card normally. - All cards hereafter must only be able to receive packets, not transmit them. Does anybody know how i can achieve this by changes in the file if_xl.c Even if you could point me to a specific subroutine it would be appreciated. Thanyou in advance Note that this card/driver seems to have serious problems under heavy load. Just so you know. It does? Have you spoken to Bill Paul about it? I dunno what it is, but we've had customers experiencing packet loss at high usage on 100Mb's nets...and the problem goes away when replacing them with intels. I dont know the details. Dennis -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
Dennis den...@etinc.com writes: At 02:58 PM 5/28/99 +0200, you wrote: I need to hack the driver file if_xl.c to do the following : Note that this card/driver seems to have serious problems under heavy load. Just so you know. What FreeBSD version do you run? There were a few commits to the xl driver shortly before 3.2 which should have ironed out whatever problems remained. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
At 03:12 AM 5/29/99 +0200, Dag-Erling Smorgrav wrote: Dennis den...@etinc.com writes: At 02:58 PM 5/28/99 +0200, you wrote: I need to hack the driver file if_xl.c to do the following : Note that this card/driver seems to have serious problems under heavy load. Just so you know. What FreeBSD version do you run? There were a few commits to the xl driver shortly before 3.2 which should have ironed out whatever problems remained. Im not sure, but Im certain that it wasnt 3.2. DB DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
Of all the gin joints in all the towns in all the world, Dennis had to walk into mine and say: Note that this card/driver seems to have serious problems under heavy load. Just so you know. This is statement is nothing more than baseless slander, just so *you* know. I really hate it when: - People claim to be having earth-shattering difficulties and then fail to provide *any* useful debugging information. You don't even tell us what version of FreeBSD you're having trouble with, or what version of the driver. (Nevermind exactly what card or what kind of machine you have it plugged into.) For all we know, your serious problems under heavy load may be due to you dropping a safe on the computer. - People have problems, fail to report them, and then wonder why things don't get fixed. 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. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@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 majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
Of all the gin joints in all the towns in all the world, Dennis had to walk into mine and say: I dunno what it is, but we've had customers experiencing packet loss at high usage on 100Mb's nets...and the problem goes away when replacing them with intels. I dont know the details. Then *FIND THEM OUT*! Replacing the cards does not fix the problem! How is anybody supposed to be able to help you if a) you never tell anybody about the trouble, b) you destroy the test configuration where the problem occurs, thereby assuring that nobody will be able to duplicate it again, and c) you don't even lift a finger to investigate! This is ridiculous! People ask me to fix stuff, they expect the world! You ask them what's going on, they don't know the details! That's just wonderful! You know, I should use that myself! Hey Bill: my network crashed. Well, there's probably something you could do to fix that but I don't know the details. Yes! I like it! Instead of trying to help people, I'll be maddeningly vague! I'll pretend to be helpful but stop short of actually providing any useful information! Then everyone else will go insane instead of me, society will collapse, and I can take over the world while everyone's distracted! You know if they ever find a way to harness sarcasm as an energy source, you people are all going to owe me big. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@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 majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
