Morty wrote:
> Tom Metro wrote:
>> So one possibility that there is something unusual in your mvpmc setup
>> that is resulting in less free memory. You might want to telnet to it
>> after a bootup and before attempting to load the recording list. Post
>> the output of 'free' and 'ps'.
>
> # free
> total used free shared buffers
> Mem: 13684 13320 364 0 3612
> Swap: 0 0 0
> Total: 13684 13320 364
I'm running an old dongle, dongle.bin.mvpmc-20080601 (I had audio
problems with newer ones, and haven't upgraded MythTV), and here is what
I see on my MVP that has been running for a week or more since the last
cold boot, and is currently in standby (powered off):
# free
total used free shared buffers
Mem: 13684 5616 8068 0 3524
Swap: 0 0 0
Total: 13684 5616 8068
So it would seem that your memory usage is substantially higher.
But maybe you captured that when mvpmc was in its active state, in which
case I see:
# free
total used free shared buffers
Mem: 13684 13208 476 0 3520
Swap: 0 0 0
Total: 13684 13208 476
which still shows 112 KB more free RAM, though in the same ballpark.
(I wonder if there is a way to get the kernel to give up the 3.5M it has
allocated to buffers. In theory, it should automatically do that as
memory demand goes up.)
> # ps
> PID Uid VmSize Stat Command
> 1 root 340 S init
> 2 root SW [keventd]
> 3 root SWN [ksoftirqd_CPU0]
> 4 root SW [kswapd]
> 5 root SW [bdflush]
> 6 root SW [kupdated]
> 7 root Z [cifsoplockd]
> 8 root SW [mtdblockd]
> 66 root 284 S /usr/sbin/telnetd
> 94 root 316 S udhcpc -i eth0 -n
> 115 root SW [rpciod]
> 133 root 920 S mvpmc -f /etc/helvB18.pcf --classic -s 192.168.13.1
> -F /media/set
> 150 root 8772 R mvpmc -f /etc/helvB18.pcf --classic -s 192.168.13.1
> -F /media/set
> 151 root 8772 S mvpmc -f /etc/helvB18.pcf --classic -s 192.168.13.1
> -F /media/set
> 152 root 8772 S mvpmc -f /etc/helvB18.pcf --classic -s 192.168.13.1
> -F /media/set
> 153 root 8772 S mvpmc -f /etc/helvB18.pcf --classic -s 192.168.13.1
> -F /media/set
> 154 root 8772 S mvpmc -f /etc/helvB18.pcf --classic -s 192.168.13.1
> -F /media/set
> 155 root 8772 S mvpmc -f /etc/helvB18.pcf --classic -s 192.168.13.1
> -F /media/set
> 156 root 8772 S mvpmc -f /etc/helvB18.pcf --classic -s 192.168.13.1
> -F /media/set
> 157 root 8772 S mvpmc -f /etc/helvB18.pcf --classic -s 192.168.13.1
> -F /media/set
> 158 root 8772 S mvpmc -f /etc/helvB18.pcf --classic -s 192.168.13.1
> -F /media/set
> 159 root 8772 S mvpmc -f /etc/helvB18.pcf --classic -s 192.168.13.1
> -F /media/set
> 160 root 8772 S mvpmc -f /etc/helvB18.pcf --classic -s 192.168.13.1
> -F /media/set
> 211 root 412 S -sh
> 215 root 344 R ps
I get (w/mvpmc active):
# ps
PID Uid VmSize Stat Command
1 root 92 S init
2 root SW [keventd]
3 root SWN [ksoftirqd_CPU0]
4 root SW [kswapd]
5 root SW [bdflush]
6 root SW [kupdated]
7 root Z [cifsoplockd]
8 root SW [mtdblockd]
66 root 108 S /usr/sbin/telnetd
96 root 56 S udhcpc -i eth0 -n
117 root SW [cifsd]
120 root SW [cifsd]
134 root 300 S mvpmc -F /tmp/settings/settings -s
192.168.0.203 -y 192.168.0.203 -u ...
152 root 104 S /bin/ntpclient -d -l -h 192.168.0.35
1635 root Z [mvpmc]
2358 root 408 S -sh
2361 root 8584 S mvpmc -F /tmp/settings/settings -s
192.168.0.203 -y 192.168.0.203 -u...
2362 root 8584 S mvpmc -F /tmp/settings/settings -s
192.168.0.203 -y 192.168.0.203 -u...
2363 root 8584 S mvpmc -F /tmp/settings/settings -s
192.168.0.203 -y 192.168.0.203 -u...
2364 root 8584 S mvpmc -F /tmp/settings/settings -s
192.168.0.203 -y 192.168.0.203 -u...
2365 root 8584 S mvpmc -F /tmp/settings/settings -s
192.168.0.203 -y 192.168.0.203 -u...
2366 root 8584 S mvpmc -F /tmp/settings/settings -s
192.168.0.203 -y 192.168.0.203 -u...
2367 root 8584 S mvpmc -F /tmp/settings/settings -s
192.168.0.203 -y 192.168.0.203 -u...
2368 root 8584 S mvpmc -F /tmp/settings/settings -s
192.168.0.203 -y 192.168.0.203 -u...
2369 root 8584 S mvpmc -F /tmp/settings/settings -s
192.168.0.203 -y 192.168.0.203 -u...
2370 root 8584 S mvpmc -F /tmp/settings/settings -s
192.168.0.203 -y 192.168.0.203 -u...
2371 root 8584 S mvpmc -F /tmp/settings/settings -s
192.168.0.203 -y 192.168.0.203 -u...
2374 root 344 R ps
Both seem comparable. Usual system processes. One mvpmc parent process
and 11 threads.
I see a few minor differences: you're running an NFS client (rpciod),
and I'm running a cifs client (cifsd). I'm running ntpclient, which you
aren't.
However, the VmSize numbers are higher for just about everything on your
MVP. If it was just the mvpmc processes, I would blame code changes or
the particular command line options you are using. But that doesn't
explain init, telnetd, and udhcpc taking 2 to 3 times more VM.
Has the BusyBox or kernel version changed? Mine has:
BusyBox v1.1.3 (2008.06.01-07:00+0000)
# cat /proc/version
Linux version 2.4.31-v1.1-hcwmvp (gettler@namba) (gcc version 3.4.5) #1
Tue Feb 20 22:58:51 CST 2007
Compiler options change? (A question for the devs on the list. We might
need to bounce this thread back over to the dev list.)
I guess we could take a closer look at the mvpmc command line options
you are using.
> I tried deleting the last recording in the log, the one immediately
> before it, and the next one in the sniffer output. No go. It still
> died at exactly the same number of recordings. It died at the same
> point (i.e. after 348 recordings), altough #348 is now a different
> recording.
OK, so further evidence that it is memory triggered.
>> -Are you using wired or wireless?
>
> I test with wired.
>
>> -Can you flood ping to/from the MVP without error?
>
> Yes.
>
>> -Have you tried a bandwidth test using the file system browser (its a
>> "context" menu option), and if so, what numbers did you achieve?
>
> I tried three times. The middle result was 16.09Mbps. The other two
> results were 12.x Mbps and 17.77Mbps.
>
>> -Do you have any playback performance issue when using the file system
>> browser?
>
> No.
So network issues are unlikely to blame.
>> -Take a look at the code (if you grok C) that is producing the error
>> message and see what it is actually testing for.
>
> I tried "make host". The host dongle isn't having this problem -- I
> can go to "watch recordings" and see a full list. The same code used
> to build an MVP dongle has this error. So it seems like the problem
> is more about resources and/or the MVP environment rather than an
> actual code issue.
Another good data point, but what I was getting at was that looking at
the place in the code where that error was triggered might give better
clues as to what was triggering it. One doesn't normally expect an error
saying the server failed to respond to be triggered by a memory
allocation error, but if the code wraps a block containing a malloc with
a timeout, them maybe that would explain it.
If so, we could also test that theory, if you are able to build a new
dongle. You could shrink the show data structure down to a few bytes and
comment out the lines that copy the data into the structure, then run
the code and see if it logs having loaded all the shows.
-Tom
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Mvpmc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mvpmc-users
mvpmc wiki: http://mvpmc.wikispaces.com/
