The loopback device is indeed supposed to simulate a network, however in a machine with a network device already working, using that IP address is faster.
The ip to my computer is 1.2.3.4. I can get almost a gigabit per second of bandwidth by ftping to 1.2.3.4 and downloading a file. FTPing to 127.0.0.1, however, results in about 10 kilobits per second. Try it yourself; I'd like to see if other people are experiencing this, or it's the odd 'just me' bug.
Adding an IP and TCP header to a packet is fast and trivial; after this the kernel picks up the packet and delivers it directly to the receiving socket. Since this is slower over localhost, I would assume perhaps there is some throttling done to traffic over localhost.
I've had the observation that localhost is extremely slow on my linux box -- for some reason I get a throughput of about 10kbit/second over localhost. This seems to happen on freebsd boxen too.
The solution to this problem is to use the actual IP address of your computer instead. I haven't tried 0.0.0.0, but that might work as well.
Why don't irc servers run linux? Here's a rather large dalnet server. Dual pII-450 (useless because ircd isn't multithreaded, but whatever:)
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND ircd 241 96.1 19.1 76772 74532 ?? R Fri09AM 3447:29.96./ircd
At the moment the server has 3200 active, open sockets. This server recieves over 150,000 client connections per day. It's currently running FreeBSD. Linux by default only supports 256 file descriptors (sockets) per process. Changing this is a complete kernel recompile. Not only that, but even after upping all the necessary settings, linux becomes unreliable after about 1024 open sockets -- the kernel randomly panics, runs out of memory, etc. Further, some kernel options simply don't work as advertised; setsockopt(SO_SNDBUF/SO_RCVBUF) cause a socket to block even if nonblocking is set.
Speaking of high-end servers, from my experience ircd has been an extremely poor performer on Alpha machines (running OSF/1); if linux fixed its shortcomings in the file descriptor area it would easily be able to run circles around OSF/1. Linux definitely has a driving force to fix this, however it's not a 'bug' per se. If FreeBSD works, which is also free, why pressure the linux developers into fixing it?
By the way, as a little offtopic note: a while back we ported ircd to win32, and I believe we even experimented with linking it to the network. One large problem turned out to be that windows would resolve machines to netbios names if they had no reverse for their ip, therefore making their address completely useless. Thank you, microsoft, for this wonderful 'feature.'
Wired homes watch an average of 13% less TV -- about one hour daily -- than others, says the study, commissioned by America Online.
To me, at first, that meant that Wired homes watch 1 hour of television. Non-wired homes on average watch 13% more? Sure, that's 68 minutes of TV instead of 60, but it makes a bit more sense to me.:) (or not)
Quicktime itself uses awful CODECs, providing poor video quality. The newer codecs are commercial and not available without a licensing fee (ie, not developed by apple). Quicktime player itself is god-awful. (QT4's user interface makes me want to kill someone at apple.) Why not distribute something in a more platform-friendly format such as mpeg-2? Quicktime player for mac and windows plays it, media player for windows plays it, and there are a bunch for linux/bsd too.
Slashdot Mirror
The ip to my computer is 1.2.3.4. I can get almost a gigabit per second of bandwidth by ftping to 1.2.3.4 and downloading a file. FTPing to 127.0.0.1, however, results in about 10 kilobits per second. Try it yourself; I'd like to see if other people are experiencing this, or it's the odd 'just me' bug.
Adding an IP and TCP header to a packet is fast and trivial; after this the kernel picks up the packet and delivers it directly to the receiving socket. Since this is slower over localhost, I would assume perhaps there is some throttling done to traffic over localhost.
The solution to this problem is to use the actual IP address of your computer instead. I haven't tried 0.0.0.0, but that might work as well.
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND ./ircd
ircd 241 96.1 19.1 76772 74532 ?? R Fri09AM 3447:29.96
At the moment the server has 3200 active, open sockets. This server recieves over 150,000 client connections per day. It's currently running FreeBSD. Linux by default only supports 256 file descriptors (sockets) per process. Changing this is a complete kernel recompile. Not only that, but even after upping all the necessary settings, linux becomes unreliable after about 1024 open sockets -- the kernel randomly panics, runs out of memory, etc. Further, some kernel options simply don't work as advertised; setsockopt(SO_SNDBUF/SO_RCVBUF) cause a socket to block even if nonblocking is set.
Speaking of high-end servers, from my experience ircd has been an extremely poor performer on Alpha machines (running OSF/1); if linux fixed its shortcomings in the file descriptor area it would easily be able to run circles around OSF/1. Linux definitely has a driving force to fix this, however it's not a 'bug' per se. If FreeBSD works, which is also free, why pressure the linux developers into fixing it?
By the way, as a little offtopic note: a while back we ported ircd to win32, and I believe we even experimented with linking it to the network. One large problem turned out to be that windows would resolve machines to netbios names if they had no reverse for their ip, therefore making their address completely useless. Thank you, microsoft, for this wonderful 'feature.'
To me, at first, that meant that Wired homes watch 1 hour of television. Non-wired homes on average watch 13% more? Sure, that's 68 minutes of TV instead of 60, but it makes a bit more sense to me. :) (or not)
Quicktime itself uses awful CODECs, providing poor video quality. The newer codecs are commercial and not available without a licensing fee (ie, not developed by apple). Quicktime player itself is god-awful. (QT4's user interface makes me want to kill someone at apple.) Why not distribute something in a more platform-friendly format such as mpeg-2? Quicktime player for mac and windows plays it, media player for windows plays it, and there are a bunch for linux/bsd too.