I have not had any hands on experience with the particular machine you are using ... But as far as generic P3 550mhz machines go, I would expect it to be adequate for the tasking as long as you were not doing a lot of fancy codec transcoding and such ...
The only thing I can think of that might be messing with you is if Asterisk is keeping the CPU so busy crunching numbers (and this would only be a factor when voice calls were active) that the routing engine fails to be responsive ... I don't think there is a tool available in Astlinux that does the equiv of the "Task Manager/Processes" in Windows ... If this was available you might be able to get a clue as to what was keeping your CPU tied up ... TOP might help you figure it out ... I am pretty sure this is available in Astlinux but it's such a primitive old tool that I pretty much ignore it ... The only other thing I might look at would be the network cards ... My 1ghz VIA machine has three Realtec 10/100 NIC's built into the motherboard ... so if I had a problem like yours I would be out of luck ... But on yours, I suspect you have the option of swapping out the network cards (at least one of them) for something known to work well ... This should be easy to do and fairly inexepensive to try ... I assume from your level of frustration that the phenomena is present even when there is no voice activity ?!?!?! Is this correct ??? And the problem goes away when you disable the packet shaping gizmo !?!?! Is this correct ??? If my understanding is correct, then this is a really odd one that is beyond me ... I have a PICMG passive backplane industrial computer with a P3 800mhz that I use as a development machine ... it seems able to handle every thing I have thrown at it ... Like you, I would have bet that a 550mhz P3 would do the job for a modest installation ... G.Hendershot -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lynn Sent: Wednesday, December 20, 2006 1:14 PM To: Discussion of AstLinux - Asterisk on Compact Flash Subject: Re: [Astlinux-users] Is it a good idea to use astlinux as a router? I've got the generic 586 0.4 load running on a Dell GX110 Pentium III 550 mhz system with 384K of ram. Is there anything I can check further? On 12/20/06, Kristian Kielhofner <[EMAIL PROTECTED]> wrote: > Tom Lynn wrote: > > Darrick, > > I completely understand. But over half of my download bandwidth > > evaporated by following the directions. I'd say I'm experiencing > > abnormal results, so I'm wondering if anybody has some advice on > > using this feature. > > > > Tom, > > What hardware are you using? > > Either way, here is the story on Linux traffic shaping... > > To properly keep track of and schedule packets, you need to > have a timing source. The Linux kernel gives you three options (at > compile > time) of which to use: > > - gettimeofday() > - timer interrupt > - TSC cycle counter > > gettimeofday() is pretty bad. > > Timer interrupt is good except that it doesn't have high enough > resolution so it becomes useless and wildly unpredictable at "high" > speeds, which I have found to be even a few megabits. > > The TSC cycle counter is best. It is only available on > Pentium/586 CPUs (another reason AstLinux requires at least a 586), is > well synchronized, and has high enough resolution to do traffic > shaping into the tens of megabits. > > However... Some CPUs turn off the TSC to save power. The > SC1100 used in the Soekris/WRAP boards is one of these. > > People (Ingmar, among others) have noticed that when Linux is > using the TSC to keep system time, for instance, NTP has trouble > keeping the system synced and in some cases either crashes or gives up > trying to because the system clock is all over the place. > > The 2.6.18 kernel introduced GTS (generic timekeeping system), > which allowed the kernel to test a series of clocks to find out which > was the most stable on a given system. Luckily, the sc1100 also has a > 27.xxx MHZ high resolution timer (scx200_hrt, I believe), that newer > kernels > (2.6.19+) can use instead of the tsc for system time. > > Back to traffic shaping... So, a couple of problems: > > - there is nothing like GTS for traffic shaping - the kernel has no > way of knowing which timing sources are accurate, and it will use > whatever it was told to use at compile time. So, if the kernel is > compiled to use TSC and you are running on a Soekris, you will get > strange results because the SC1100 will go into standby and throw off your traffic shaping. > > - timer interrupt/gettimeofday() aren't really practical for low > powered embedded systems that need to do traffic shaping on "modern" > internet connections > > However, there is a work-around for the sc1100 boards - if you > pass "idle=poll" on the kernel command line AND you are using the TSC, > you should have pretty good traffic shaping results with those boards. > The only problem is it will use more power and generate more heat. In > my very preliminary tests, it ran the CPU ~7 degrees (F) hotter than > normal after about 24 hours of operation. YMMV. > > As far as traffic shaping goes in general... Yes, to do > effective traffic shaping with VoIP services on "standard" internet > connections, you really should limit the overall transfer capacity to > about %90 of what is capable on the link. > > Just like Darren described, if you don't artificially limit the > speed of the link your ISP will, and their send queues are not tuned > like yours are... So, if you run at %100, and they start queuing, > they are going to use whatever algorithm that they have (probably a > simple FIFO with a buffer) to schedule outgoing packets. This isn't what you want! > Limiting the speed of the link prevents this queuing and will give > you a better experience for VoIP (and any other service that uses > large amounts of relatively small packets - gaming for instance). > > In summary, yes, using astshape will reduce the speed of your > link by about %10. However, the results that you are seeing could be > a result of using the timer interrupt for QoS, or, a misbehaving TSC > on your system. The question again is: what hardware are you using? > > -- > Kristian Kielhofner > _______________________________________________ > Astlinux-users mailing list > [email protected] > http://lists.kriscompanies.com/mailman/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to [EMAIL PROTECTED] > _______________________________________________ Astlinux-users mailing list [email protected] http://lists.kriscompanies.com/mailman/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to [EMAIL PROTECTED] _______________________________________________ Astlinux-users mailing list [email protected] http://lists.kriscompanies.com/mailman/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to [EMAIL PROTECTED]
