Re: Tools used accounting/billing
### On Tue, 5 Mar 2002 15:35:59 -0800, H. Michael Smith, Jr. ### [EMAIL PROTECTED] casually decided to expound upon ### [EMAIL PROTECTED] the following thoughts about Tools used ### accounting/billing: HMS Can anyone suggest tools to use for gathering statistics for billing HMS purposes? I would like to know what tools are most common among ISPs. Depends on how you're billing and how complex a network you have. At the provider I worked at, we billed based on rate and so we collected port level statistics, calculated rate fron in/out octets as needed, and generated billing from that. Our tools were at first homegrown (mainly perl based snmp collectors) but we had started looking at commercial vendor solutions too. One very large requirement was that of fault-tolerance. Having your pollers in one or two locations means you can lose valuable port utilisation statistics during even a small network outage due to counter rollovers at high linerates. It was important to be able to scale out a large number of collectors positioned close in to the target devices with the ability to fall back to a store-and-forward mode and remain there for extended periods of time in case WAN connectivity to the datastore fails and then recover and merge data once connectivity was restored. It was also important to have backup and failover capabilities built into the collector so that a poller/collector could take over for one that has failed. One of the vendors that impressed us was RiverSoft since their architecture lent itself well to establishing a scalable fault-tolerant deployment and was engineered along similar design principles as our homegrown tools. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: Satellite latency
On Tue, Mar 05, 2002 at 03:52:31PM -0800, Clayton Fiske wrote: kernel buffer and will misreport speed). Open a few more connections like that and you've exausted your kernel memory and most likely will have a panic. If you did these settings on a web server, all it would take is a few dialups trying to download a big file before you go boom. Since this buffer is determined by the receive window (and thus by the receiving system), I don't see why it matters. Most receivers will be using OS defaults, and the ones who adjust their receive window size up are probably doing so because they have a fast enough link to warrant it. I can't see where a dialup user would find any cause to give himself a huge receive window. No, the buffer is determined by the configured socket buffer size, the rate at which TCP drains the socket buffer on the network is determined in part by the advertised receive window. So if you run a web server and try to turn up your socket buffers to some big number thinking you'll get better performance, and a dialup user connects and tries to download a 1MB file, the web server will immediately dump 1MB into the kernel until either the socket buffer or the file runs out, and then the kernel will spend the 5 minutes transfering it to the dialup user. Have that happen a few times, and you get an instant mbuf exaustion (or whatever internal mechanism your OS of choice uses) and kernel panic... -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
