[App_rpt-users] Beagleboard and USB URI dongle

Sun Feb 20 18:41:41 UTC 2011

I really would not be horribly shocked if the SCSI/SDA drivers do something nasty and take too much time
and interfere with the proper operation of the Zaptel driver.

Linux... the great experiment..

JIM WB6NIL

> Date: Sun, 20 Feb 2011 13:30:43 -0500
> Subject: RE: [App_rpt-users] Beagleboard and USB URI dongle
> From: steve at michiganbroadband.com
> To: telesistant at hotmail.com
> CC: steve at michiganbroadband.com; app_rpt-users at ohnosec.org; yokshs at sbcglobal.net
> 
> Certainly does!!
> So you also remember distros shipping with all the IDE enhanced stuff turned
> off and actually using hdparm on startup to SET some performance options
> too eh?
> Wow that was a long time ago!
> 
> Anyhow I've not tested on IDE yet and none of those options apply
> to the 'ol SCSI system I have up & testing at the moment. :-)
> (It won't accept those options).
> 
> But aside from that it looks like I've identified one easy test
> that reliably 'interrupts' the usb audio routine and demonstrates
> that something is or can punch noticeable holes in it. :-)
> 
> 
> I've not tested IDE yet (coming soon) :-)
> 
> -Steve
> 
> 
> 
> 
> 
> 
> >
> > Boy, this brings back some ancient memories...
> >
> > Referring to http://www.zapatatelephony.org/linux.html
> >
> > "Also, at system startup, hdparm
> > must
> > be run with the -c1 -d1 -u1 flags. This enables 32 bit
> > I/O, DMA, and the
> > unmaskinterrupt flag. This allows the IDE driver not to interfere with
> > the tormenta
> > driver."
> >
> > Now, after 11 years, it hasnt changed too much. The "tormenta" driver was
> > renamed the "Zaptel" driver and then renamed the "DAHDI"
> > driver, and people are more likely to be using the SCSI (SATA) driver, but
> > the issue is just as valid.
> >
> > Try doing that. I bet that you wont have any more problems with hdparm -t
> > anymore.
> >
> > I sure "tormented" many Linux boxes with hdparm -t a long time ago. :-)
> >
> > JIM WB6NIL
> >
> >
> >> Date: Sun, 20 Feb 2011 12:53:09 -0500
> >> From: steve at michiganbroadband.com
> >> To: steve at michiganbroadband.com
> >> CC: app_rpt-users at ohnosec.org; yokshs at sbcglobal.net
> >> Subject: Re: [App_rpt-users] Beagleboard and USB URI dongle
> >>
> >> OK, looking back through my old notes I have a note that mentions that
> >> the
> >> audio drop occurs *sometimes* while apt_rpt is doing it's HTTP data
> >> reporting to allstarlink..
> >>
> >> This is *still* happening but not all the time or consistently..
> >>  But sometimes and very noticeably the audio pops occur at the same time
> >> app_rpt sends it's stats.
> >>
> >>
> >> I did however recently find another test where I can cause the audio
> >> dropout
> >> to occur about 90% of the time which is far more consistent than waiting
> >> for app_rpt to do it's stat push.
> >>
> >> By running hdparm -t
> >>
> >> In my case it's:
> >>
> >> hdparm -t /dev/ida/c0d0p1
> >>
> >> Just as the program exits it makes the audio popping..
> >> *almost* every time.
> >>
> >> Oddly ad frustratingly it's *almost* every time..
> >> Not really sure why 10% of the time it doesn't happen..
> >> But be come kind of narrow timing window thing going on here.
> >> But *where*?
> >>
> >> Especially if you wait 5-10 seconds (or more) before running it again.
> >>
> >>
> >> This is the ONLY way in 2 years I've been able to induce the popping
> >> myself from a test.
> >> Otherwise it happens randomly as mentioned previously.
> >>
> >> A couple quick related notes is that the problem does *not* occur
> >> when running hdparm -T instead (buffer speed test)
> >>
> >> Nor when you manually flush the drive cache by running the sync command.
> >>
> >> Other activities that test the hard drive (large file copies etc.) do
> >> not
> >> induce the problem.
> >>
> >> That test is on a SCSI RAID5 array server..
> >> Not tried it on a plain jane IDE system yet
> >>
> >> hdparm -t /dev/ida/c0d0p1 (Makes 3-4 definite audio pops in succession
> >> on
> >> exit)
> >>
> >> /dev/ida/c0d0p1:
> >>  Timing buffered disk reads:   72 MB in  3.06 seconds =  23.56 MB/sec
> >> [root at MBB001 ~]#
> >> [root at MBB001 ~]#
> >> [root at MBB001 ~]#
> >> [root at MBB001 ~]# hdparm -T /dev/ida/c0d0p1
> >>
> >>
> >>
> >>
> >>
> >> /dev/ida/c0d0p1: (no pops EVER)
> >>  Timing cached reads:   776 MB in  2.00 seconds = 388.05 MB/sec
> >>
> >>
> >> -Steve
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> > Hi Chuck..
> >> >
> >> > My box (pretty much a fresh ACID install) does not even have NTPD
> >> > running on it.
> >> >
> >> > What I did try was running the heck out of ntpdate which has
> >> absolutely
> >> > no effect whatsoever on the audio as it does it's thing syncing the
> >> clock.
> >> >
> >> > I've done a LOT of other 'similar' tests like this over the past year
> >> > trying to find something that influences the behavior or induces it to
> >> > occur.
> >> >
> >> > While I was at it I also ran <hwclock --systohc> just for kicks.
> >> >
> >> > Again about anything I can think of does not cause the issue to
> >> surface..
> >> > It just does it on it's own seemingly randomly.
> >> >
> >> > In it's little subtle irritating way :-)
> >> >
> >> > And just for convenience... a video from Nov 14 2009.
> >> >
> >> > Radio Key command listening to PL and the issue. :-)
> >> >
> >> >
> >> > http://www.youtube.com/watch?v=lqYwhtuVLDs
> >> >
> >> >
> >> >
> >> > -Steve
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >> Why not run ntpd and keep your clock in sync all the time instead of
> >> >> once an hour :)
> >> >>
> >> >> Jim, K6JWN
> >> >>
> >> >> On Thu, Feb 17, 2011 at 01:09:17AM -0600, Chuck Henderson
> >> >> <rpt2 at chuck.midlandsnetworking.com> said:
> >> >>
> >> >>> When I started using this software I noticed the audio issues in my
> >> >>> test
> >> >>> environment.  I tried a dozen different mothertboard/CPU
> >> combinations
> >> >>> and 3
> >> >>> different USB fobs.  I found that the faster the system the
> >> >>> less noticeable the issues but even a 3.4 GHZ quad core still had
> >> the
> >> >>> issues.  I experimented with a lot of variables and several things
> >> made
> >> >>> some
> >> >>> difference but the single most significant thing that reduced the
> >> issue
> >> >>> was stopping ntpd.  I now run ntpdate 40 seconds after the hour,
> >> every
> >> >>> hour.
> >> >>>  This keeps the date and time close enough and greatly reduces the
> >> >>> audio
> >> >>> glitch like sounds that I was noticing.  Also I found that when the
> >> >>> system
> >> >>> is not under test and is using real hand held and mobile stations
> >> >>> working
> >> >>> through the repeater that the remaining audio glitch like sounds
> >> >>> are indistinguishable from typical normal radio noise hits.  By the
> >> >>> way,
> >> >>> my
> >> >>> final choice for a system board is the D510MO.
> >> >>> While I do not know for sure, I suspect that when ntpd makes tiny
> >> >>> adjustments to the system time, this results in tiny glitches in the
> >> >>> processing in the USB sound system.  I am clueless how to track it
> >> down
> >> >>> any
> >> >>> further, and do not see any need.
> >> >>> Chuck
> >> >>
> >> >> --
> >> >> This message has been scanned for viruses and
> >> >> dangerous content by MailScanner, and is
> >> >> believed to be clean.
> >> >>
> >> >
> >> >
> >> > Michigan Broadband Systems Inc.
> >> > "Always Connected"
> >> >
> >> > (734)527-7150
> >> >
> >> > Steve's cellphone: (734)904-1811
> >> >
> >> >
> >> > --
> >> > This message has been scanned for viruses and
> >> > dangerous content by MailScanner, and is
> >> > believed to be clean.
> >> >
> >>
> >>
> >> Michigan Broadband Systems Inc.
> >> "Always Connected"
> >>
> >> (734)527-7150
> >>
> >> Steve's cellphone: (734)904-1811
> >>
> >>
> >> --
> >> This message has been scanned for viruses and
> >> dangerous content by MailScanner, and is
> >> believed to be clean.
> >>
> >> _______________________________________________
> >> App_rpt-users mailing list
> >> App_rpt-users at ohnosec.org
> >> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> >
> >
> 
> 
> Michigan Broadband Systems Inc.
> "Always Connected"
> 
> (734)527-7150
> 
> Steve's cellphone: (734)904-1811
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.keekles.org/pipermail/app_rpt-users/attachments/20110220/3e159776/attachment.html>