Agreed.
It definitely needs to be documented. We spent about a week
chasing down the performance problem. The default priority of
QNET is so low that screen scrolling can block it.
The UDP/TCP/IP stack behavior in this area should be documented
too.
John Nagle
Xiaodan Tang wrote:
There are some places inside the QNET, a thread wake up for an
internal event, we need to “pick a priority” for these thread.For example, the timer pulse. When timer goes off, a pulse fired, thread
will adjust to the pulse priority, but which priority it should be?Most of other code, (stack, io-net) are fixed for allow user to specify
the priority of this kind of “internal event priority”, from command line
option.The 6.2.1 QNET happened to choose “base priority”, which basiclly
is the priority it get initialized, as this internal priority. By raising
the mount
priority, the io-net thread who handle the mount request inherit that
priority, and load/initialize QNET with that priority.I won’t call this behavior a bug, but agree a command line option
(to adjust this priority) would be more obverious to users.-xtang
John Nagle <> nagle@downside.com> > wrote in message
news:coic2s$hj5$> 1@inn.qnx.com> …Bill Caroselli wrote:
John Nagle <> nagle@downside.com> > wrote:
JN > Xiaodan Tang wrote:
When you “mount -Tio-net npm-qnet.so”, try raise the priorities line
“on -p 16 mount -Tio-net npm-qnet.so”, and see if that helps you?-xtang
JN > That works. Thanks. With that mount at priority 16,
JN > GUI activity no longer stalls QNET. I’m not missing a
JN > single time-critical response now, no matter what I do at user
JN > level.Please explain why the priority of the mount command has an effect on
the
priority that io-net runs QNET at?
Presumably the mount command is starting the threads that
actually do the work, and so they inherit the priority of the
mount command.Someone with access to the source code should answer this one.
It’s not clear whether it should happen this way or whether it’s
a bug. But it’s real.John Nagle
Team Overbot