Loading ...
Sorry, an error occurred while loading the content.

Re: Odd Laptop/WiFi Interference

Expand Messages
  • eriksradio
    Hi Joanne; With due respect, I will take on that bet. I challenge you to change the thread priority of the RX and TX threads in EasyPal. You could do it within
    Message 1 of 8 , Mar 1, 2009
    • 0 Attachment
      Hi Joanne;

      With due respect, I will take on that bet.
      I challenge you to change the thread priority of the RX and TX
      threads in EasyPal.

      You could do it within hamdrm.dll. You will not otherwise.
      hamdrm.dll is freely available along with the source code if you
      wish to have a go..

      It would be simply disastrous to reduce the priority in the RX and
      TX threads.
      We all know what happens in MMSSTV, PSK31 etc.
      You can do it with these. I did it.

      Thread priority is extremely complex, and a tribute to the
      designers that the RX and TX threads are so stable.

      If you can do it, I will take more notice of your comments.
      There is too much "armchair" chatter with little substance.
      Just do it.

      Erik VK4AES



      --- In digsstv@yahoogroups.com, "jdow" <jdow@...> wrote:
      >
      > From: "eriksradio" <esundstrup@...>
      > Sent: Saturday, 2009, February 28 19:47
      >
      >
      > > Re the UP the priority in EasyPal.
      > > It will be interesting to see the results of any experiments.
      > >
      > > EasyPal consists of three main threads.
      > > The RX and TX threads are always set to HIGH priority.
      > > This cannot be changed.
      >
      > Do not bet on that. The way thread priority is set is complex and
      > values will overlap. If you raise the process priority that sets
      > a band in which the thread priorities operate. To get operation
      > that is really "real time" you need to set the threads to that
      > priority and set the process to the realtime priority. Then if
      you
      > take too much time when you've asked for processor time, the
      system
      > goes down. Setting the process to real time with the threads set
      > to normal is not nearly as bad because items set to real-real
      still
      > get a chance to run.
      >
      > It's a complex issue along with dynamic priority manipulation by
      the
      > OS. I've listened to Loren explain it before and got about 90%
      of it.
      > He's done kernel HAL hacking for UniSys - and taught Microsoft
      what
      > UniSys knew about dynamic partitioning on 64 processor behemoths
      > when you want to partition them into three or four seemingly
      separate
      > machines all the way down to the interrupts.
      >
      > So if you are set to high on thread priority bumping it up a
      notch or
      > maybe two in taskmanager might make a worthwhile difference. And
      of
      > course, YMMV heavily depending on what else is going on and how
      the
      > <censored> drivers are written.
      >
      > {^_-} Joanne W6MKU
      >
      > === all old stuff below cut line ===8<-----
      >
      > > The RX and TX do not want to be interrupted by other things
      going on
      > > in the computer.
      > >
      > > This leaves the main program as the only thread that can be
      changed.
      > >
      > > The various possible settings are
      > >
      > > THREAD_PRIORITY_IDLE
      > > THREAD_PRIORITY_LOWEST
      > > THREAD_PRIORITY_BELOW_NORMAL
      > > THREAD_PRIORITY_NORMAL
      > > THREAD_PRIORITY_ABOVE_NORMAL
      > > THREAD_PRIORITY_HIGHEST
      > > THREAD_PRIORITY_TIME_CRITICAL
      > >
      > > Setting to the higest level TIME_CRITICAL may introduce
      instability.
      > > I have played with the two highest settings and get a very
      occassional
      > > "blue screen of death". Different systems will behave
      differently.
      > >
      > > Setting to the lowest may not have any noticeable effect
      unless other
      > > things are in progress such as a downloading, streaming video
      etc etc.
      > > If any of these processes have been set to TIME_CRITICAL; then
      higher
      > > settings in EasyPal will have no effect.
      > >
      > > In low settings the waterfall may be jumpy and other things
      seem slow.
      > > But only while the other computer processes are active.
      > >
      > > Setting to lowest may be the most stable, but annoying
      sometimes.
      > >
      > > I will leave EasyPal set to normal priority; but users can
      force
      > > higher settings for experiments.
      > >
      > > In the long run, it is probably best to leave alone and let
      Windows
      > > sort it out. Some will have success and others lots of "blue
      screens".
      > >
      > > Erik VK4AES
      > >
      > >
      > >
      > >
      > >
      > > --- In digsstv@yahoogroups.com, "jdow" <jdow@> wrote:
      > >>
      > >> Here's an idea. But play with it with extreme caution.
      > >>
      > >> Some background first
      > >> One of the "thingies" I make is a set of DLLs that load
      into the
      > >> system designed to look like MIDI devices. In the process of
      testing
      > >> the transport device that sends MIDI from one machine to
      another
      > > over
      > >> Ethernet we ran across process priority issues. This was in
      the
      > > really
      > >> early days of NT4. (I never even THOUGHT of trying this with
      the 3.x
      > >> family - which ran through ME.)
      > >>
      > >> We played a standard MIDI file through the media player to
      another
      > >> computer time stamping the results to microseconds. We
      compared the
      > >> actual times of receipt with the scheduled times of receipt
      as well
      > >> as compared multiple runs with each other.
      > >>
      > >> We found that at its normal priority Media Player was
      MISERABLE on
      > >> timing, 100ms to 500ms or worse jitter peak to peak. We
      raised the
      > >> priorities on both ends to high priority and to real time
      priority.
      > >> Each step improved performance with Real Time priority giving
      as
      > >> little as 2ms RMS jitter on a thin-net Ethernet interface.
      > >>
      > >> So with that in mind it might be interesting for you to
      modify the
      > >> priority on EasyPAL using TaskManager. Bring up TaskManager.
      Select
      > >> the Processes tab. Look for EasyPal in the process list.
      Right click
      > >> on it. Select the next higher priority, above normal. See if
      that
      > >> improves reception. Try the higher than normal to see if
      there is
      > >> another improvement. Only if it is ABSOLUTELY necessary go up
      to the
      > >> RealTime priority.
      > >>
      > >> I bet it makes a difference. Reporting your results to the
      group
      > > here
      > >> might lead to a couple extra lines of code in EasyPal to set
      its
      > >> base priority a little higher than normal. That also works
      for
      > > things
      > >> like MMSSTV, PSK-31 software, and the like.
      > >>
      > >> {^_^} Joanne W6MKU
      > >> ----- Original Message -----
      > >> From: "RobertCGRO" <robertcgro@>
      > >> Sent: Friday, 2009, February 27 17:56
      > >>
      > >>
      > >> > Thanks, Dave.
      > >> >
      > >> > Yes, I noticed that on receive it was 100 percent which
      surprised
      > > me as
      > >> > well!
      > >> >
      > >> > Got a reply back from another user group, and he seemed to
      think
      > > that
      > >> > the WiFi card is sending interupt requests to the CPU (for
      > > whatever
      > >> > reason) when the soundcard is doing digital output but not
      input.
      > > Most
      > >> > laptops have a sofstware modem hooked into the audio
      system, but
      > >> > disabling it didn't fix the problem, nor just disabling the
      Wifi
      > > card.
      > >> > I have to either physically remove the PCMIA WiFi card form
      my old
      > >> > laptop, or turn it off with the side switch for my Dell duo-
      core.
      > >> >
      > >> > He also mentioned that it's recommened not to use onboard
      > > soundcards
      > >> > with laptops and go with a USB one like the SignaLink and
      some
      > > others
      > >> > on the market. I picked up a few USB soundcards from
      > > dealextreme.com
      > >> > surper cheap (China). The problem wasn't as bad, but I
      still had
      > > the
      > >> > odd click, pop, stutter if the Wifi wasn't disabled
      completely.
      > >> >
      > >> > At least I'm not going crazy. I'm going to install Linux
      and load
      > > up
      > >> > FLDIGI and some other Linux ham software. I want to see if
      Linux
      > > has
      > >> > the same kind of problem, and if not I'll dump Windows
      altogether.
      > > I'm
      > >> > sick and tired of the buggy software MS OS crap and
      constanly
      > > having to
      > >> > reinstall the OS because of problems like this. Took me 3
      months
      > > just
      > >> > get a stable Vista box. Now, it's being dropped for Windows
      7 this
      > > fall.
      > >> >
      > >> > Thanks es 73,
      > >> > Robert, VA3ROM
      > >> >
      > >> >
      > >> >
      > >> >
      > >> > --- In digsstv@yahoogroups.com, "w5dbk" <w5dbk.dave@> wrote:
      > >> >>
      > >> >> I had a similar problem with a Dell mini 9 except it was
      > >> >> intermittent. While I was sending a picture, the
      receiving
      > > station
      > >> >> would lose sync for a few seconds and then pick back up.
      I did a
      > >> >> complete re-insstall of XP on the Dell mini and then
      loaded the
      > >> >> drivers back in one at a time. During that process is
      when I
      > > found
      > >> >> that EasyPal would not load (can't find hamdrm.dll) unless
      there
      > > is a
      > >> >> driver installed for the sound card). When I got to the
      wifi
      > > driver
      > >> >> I knew I had found it. I now keep a note on the PC to
      turn off
      > > the
      > >> >> wifi during EasyPal. I was surprised that the problem
      showed up
      > > only
      > >> >> during xmit, not during receive.
      > >> >>
      > >> >> Dave
      > >> >> W5DBK
      > >> >
      > >> >
      > >> >
      > >> >
      > >> > ------------------------------------
      > >> >
      > >> > Yahoo! Groups Links
      > >> >
      > >> >
      > >> >
      > >>
      > >
      > >
      > >
      > >
      > >
      > > ------------------------------------
      > >
      > > Yahoo! Groups Links
      > >
      > >
      > >
      >
    • jdow
      Erik, I am simply addressing the internals of Windows and how the priorities actually work once they get to the kernel. The thread priorities are modifiers on
      Message 2 of 8 , Mar 1, 2009
      • 0 Attachment
        Erik, I am simply addressing the internals of Windows and how
        the priorities actually work once they get to the kernel. The
        thread priorities are modifiers on the process priority. At
        least that is what I've been assured of over over again. You
        need both process and thread priorities to determine what the
        final nominal priority of a thread will be as seen by the kernel.

        (And as for changing thread priorities - erm - get me into a
        debugger and it's not hard to fiddle it. It is easiest to simply
        use the ::SetThreadPriority() function. But it can be done in a
        debugger, too. The process priority is set with the
        ::SetPriorityClass() function.)

        For the process as a whole:

        HANDLE curproc = GetCurrentProcess( );
        SetPriorityClass( curproc, HIGH_PRIORITY_CLASS );

        For the thread:
        SetThreadPriority( m_hThread, THREAD_PRIORITY_TIME_CRITICAL );

        That was used for a project with only 10 or 20 threads in it depending
        on options enabled. It processed video for broadcast TV. That was the
        field interrupt clock spawned from the process with the "HIGH_PRIORITY..."
        setting.

        The thing I am working on now is fussier. It runs about 40 to 100 threads
        all the time. It's doing fancier video.

        The function calls above are direct out of the Microsoft SDK. This is
        why I suggest a gentle bump in priority in EasyPAL until it is seen to
        give trouble. One bump will get it's GUI out of the general system GUI
        refresh cycle so it's not delayed as much.

        {^_-} Joanne, W6MKU

        ----- Original Message -----
        From: "eriksradio" <esundstrup@...>
        Sent: Sunday, 2009, March 01 00:06


        > Hi Joanne;
        >
        > With due respect, I will take on that bet.
        > I challenge you to change the thread priority of the RX and TX
        > threads in EasyPal.
        >
        > You could do it within hamdrm.dll. You will not otherwise.
        > hamdrm.dll is freely available along with the source code if you
        > wish to have a go..
        >
        > It would be simply disastrous to reduce the priority in the RX and
        > TX threads.
        > We all know what happens in MMSSTV, PSK31 etc.
        > You can do it with these. I did it.
        >
        > Thread priority is extremely complex, and a tribute to the
        > designers that the RX and TX threads are so stable.
        >
        > If you can do it, I will take more notice of your comments.
        > There is too much "armchair" chatter with little substance.
        > Just do it.
        >
        > Erik VK4AES
        >
        >
        >
        > --- In digsstv@yahoogroups.com, "jdow" <jdow@...> wrote:
        >>
        >> From: "eriksradio" <esundstrup@...>
        >> Sent: Saturday, 2009, February 28 19:47
        >>
        >>
        >> > Re the UP the priority in EasyPal.
        >> > It will be interesting to see the results of any experiments.
        >> >
        >> > EasyPal consists of three main threads.
        >> > The RX and TX threads are always set to HIGH priority.
        >> > This cannot be changed.
        >>
        >> Do not bet on that. The way thread priority is set is complex and
        >> values will overlap. If you raise the process priority that sets
        >> a band in which the thread priorities operate. To get operation
        >> that is really "real time" you need to set the threads to that
        >> priority and set the process to the realtime priority. Then if
        > you
        >> take too much time when you've asked for processor time, the
        > system
        >> goes down. Setting the process to real time with the threads set
        >> to normal is not nearly as bad because items set to real-real
        > still
        >> get a chance to run.
        >>
        >> It's a complex issue along with dynamic priority manipulation by
        > the
        >> OS. I've listened to Loren explain it before and got about 90%
        > of it.
        >> He's done kernel HAL hacking for UniSys - and taught Microsoft
        > what
        >> UniSys knew about dynamic partitioning on 64 processor behemoths
        >> when you want to partition them into three or four seemingly
        > separate
        >> machines all the way down to the interrupts.
        >>
        >> So if you are set to high on thread priority bumping it up a
        > notch or
        >> maybe two in taskmanager might make a worthwhile difference. And
        > of
        >> course, YMMV heavily depending on what else is going on and how
        > the
        >> <censored> drivers are written.
        >>
        >> {^_-} Joanne W6MKU
        >>
        >> === all old stuff below cut line ===8<-----
        >>
        >> > The RX and TX do not want to be interrupted by other things
        > going on
        >> > in the computer.
        >> >
        >> > This leaves the main program as the only thread that can be
        > changed.
        >> >
        >> > The various possible settings are
        >> >
        >> > THREAD_PRIORITY_IDLE
        >> > THREAD_PRIORITY_LOWEST
        >> > THREAD_PRIORITY_BELOW_NORMAL
        >> > THREAD_PRIORITY_NORMAL
        >> > THREAD_PRIORITY_ABOVE_NORMAL
        >> > THREAD_PRIORITY_HIGHEST
        >> > THREAD_PRIORITY_TIME_CRITICAL
        >> >
        >> > Setting to the higest level TIME_CRITICAL may introduce
        > instability.
        >> > I have played with the two highest settings and get a very
        > occassional
        >> > "blue screen of death". Different systems will behave
        > differently.
        >> >
        >> > Setting to the lowest may not have any noticeable effect
        > unless other
        >> > things are in progress such as a downloading, streaming video
        > etc etc.
        >> > If any of these processes have been set to TIME_CRITICAL; then
        > higher
        >> > settings in EasyPal will have no effect.
        >> >
        >> > In low settings the waterfall may be jumpy and other things
        > seem slow.
        >> > But only while the other computer processes are active.
        >> >
        >> > Setting to lowest may be the most stable, but annoying
        > sometimes.
        >> >
        >> > I will leave EasyPal set to normal priority; but users can
        > force
        >> > higher settings for experiments.
        >> >
        >> > In the long run, it is probably best to leave alone and let
        > Windows
        >> > sort it out. Some will have success and others lots of "blue
        > screens".
        >> >
        >> > Erik VK4AES
        >> >
        >> >
        >> >
        >> >
        >> >
        >> > --- In digsstv@yahoogroups.com, "jdow" <jdow@> wrote:
        >> >>
        >> >> Here's an idea. But play with it with extreme caution.
        >> >>
        >> >> Some background first
        >> >> One of the "thingies" I make is a set of DLLs that load
        > into the
        >> >> system designed to look like MIDI devices. In the process of
        > testing
        >> >> the transport device that sends MIDI from one machine to
        > another
        >> > over
        >> >> Ethernet we ran across process priority issues. This was in
        > the
        >> > really
        >> >> early days of NT4. (I never even THOUGHT of trying this with
        > the 3.x
        >> >> family - which ran through ME.)
        >> >>
        >> >> We played a standard MIDI file through the media player to
        > another
        >> >> computer time stamping the results to microseconds. We
        > compared the
        >> >> actual times of receipt with the scheduled times of receipt
        > as well
        >> >> as compared multiple runs with each other.
        >> >>
        >> >> We found that at its normal priority Media Player was
        > MISERABLE on
        >> >> timing, 100ms to 500ms or worse jitter peak to peak. We
        > raised the
        >> >> priorities on both ends to high priority and to real time
        > priority.
        >> >> Each step improved performance with Real Time priority giving
        > as
        >> >> little as 2ms RMS jitter on a thin-net Ethernet interface.
        >> >>
        >> >> So with that in mind it might be interesting for you to
        > modify the
        >> >> priority on EasyPAL using TaskManager. Bring up TaskManager.
        > Select
        >> >> the Processes tab. Look for EasyPal in the process list.
        > Right click
        >> >> on it. Select the next higher priority, above normal. See if
        > that
        >> >> improves reception. Try the higher than normal to see if
        > there is
        >> >> another improvement. Only if it is ABSOLUTELY necessary go up
        > to the
        >> >> RealTime priority.
        >> >>
        >> >> I bet it makes a difference. Reporting your results to the
        > group
        >> > here
        >> >> might lead to a couple extra lines of code in EasyPal to set
        > its
        >> >> base priority a little higher than normal. That also works
        > for
        >> > things
        >> >> like MMSSTV, PSK-31 software, and the like.
        >> >>
        >> >> {^_^} Joanne W6MKU
        >> >> ----- Original Message -----
        >> >> From: "RobertCGRO" <robertcgro@>
        >> >> Sent: Friday, 2009, February 27 17:56
        >> >>
        >> >>
        >> >> > Thanks, Dave.
        >> >> >
        >> >> > Yes, I noticed that on receive it was 100 percent which
        > surprised
        >> > me as
        >> >> > well!
        >> >> >
        >> >> > Got a reply back from another user group, and he seemed to
        > think
        >> > that
        >> >> > the WiFi card is sending interupt requests to the CPU (for
        >> > whatever
        >> >> > reason) when the soundcard is doing digital output but not
        > input.
        >> > Most
        >> >> > laptops have a sofstware modem hooked into the audio
        > system, but
        >> >> > disabling it didn't fix the problem, nor just disabling the
        > Wifi
        >> > card.
        >> >> > I have to either physically remove the PCMIA WiFi card form
        > my old
        >> >> > laptop, or turn it off with the side switch for my Dell duo-
        > core.
        >> >> >
        >> >> > He also mentioned that it's recommened not to use onboard
        >> > soundcards
        >> >> > with laptops and go with a USB one like the SignaLink and
        > some
        >> > others
        >> >> > on the market. I picked up a few USB soundcards from
        >> > dealextreme.com
        >> >> > surper cheap (China). The problem wasn't as bad, but I
        > still had
        >> > the
        >> >> > odd click, pop, stutter if the Wifi wasn't disabled
        > completely.
        >> >> >
        >> >> > At least I'm not going crazy. I'm going to install Linux
        > and load
        >> > up
        >> >> > FLDIGI and some other Linux ham software. I want to see if
        > Linux
        >> > has
        >> >> > the same kind of problem, and if not I'll dump Windows
        > altogether.
        >> > I'm
        >> >> > sick and tired of the buggy software MS OS crap and
        > constanly
        >> > having to
        >> >> > reinstall the OS because of problems like this. Took me 3
        > months
        >> > just
        >> >> > get a stable Vista box. Now, it's being dropped for Windows
        > 7 this
        >> > fall.
        >> >> >
        >> >> > Thanks es 73,
        >> >> > Robert, VA3ROM
        >> >> >
        >> >> >
        >> >> >
        >> >> >
        >> >> > --- In digsstv@yahoogroups.com, "w5dbk" <w5dbk.dave@> wrote:
        >> >> >>
        >> >> >> I had a similar problem with a Dell mini 9 except it was
        >> >> >> intermittent. While I was sending a picture, the
        > receiving
        >> > station
        >> >> >> would lose sync for a few seconds and then pick back up.
        > I did a
        >> >> >> complete re-insstall of XP on the Dell mini and then
        > loaded the
        >> >> >> drivers back in one at a time. During that process is
        > when I
        >> > found
        >> >> >> that EasyPal would not load (can't find hamdrm.dll) unless
        > there
        >> > is a
        >> >> >> driver installed for the sound card). When I got to the
        > wifi
        >> > driver
        >> >> >> I knew I had found it. I now keep a note on the PC to
        > turn off
        >> > the
        >> >> >> wifi during EasyPal. I was surprised that the problem
        > showed up
        >> > only
        >> >> >> during xmit, not during receive.
        >> >> >>
        >> >> >> Dave
        >> >> >> W5DBK
        >> >> >
        >> >> >
        >> >> >
        >> >> >
        >> >> > ------------------------------------
        >> >> >
        >> >> > Yahoo! Groups Links
        >> >> >
        >> >> >
        >> >> >
        >> >>
        >> >
        >> >
        >> >
        >> >
        >> >
        >> > ------------------------------------
        >> >
        >> > Yahoo! Groups Links
        >> >
        >> >
        >> >
        >>
        >
        >
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.