[App_rpt-users] Beagleboard and USB URI dongle

Sun Feb 20 18:23:41 UTC 2011

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

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