Sorry my hd is a usb external one if it's any us.
Code:
You don't have permission to view the code content. Log in or register now.
Jtag'd TM800 Vs normal
- Thread starter digidude
- Start date
Thank you Ellie. In theory it should be slower than the internal sata, but that is an excellent result, not far off the maximum that the usb supports and x10 better than tests on the original.
I've just dug out a 3Ghz sata disk in a usb cradle and repeated your test on the original box, as shown below. I get an expected result of one tenth the speed you report. This suggests that the fix should indeed resolve all the issues with the box as that speed can support dual HD channel and simultaneous playback.
I've just dug out a 3Ghz sata disk in a usb cradle and repeated your test on the original box, as shown below. I get an expected result of one tenth the speed you report. This suggests that the fix should indeed resolve all the issues with the box as that speed can support dual HD channel and simultaneous playback.
Last edited:
@ Jimux, just fitted an internal drive into a jtag'd receiver, results are below
PLi® openpli TM800
192.168.1.180 login: root
Password:
Running /etc/profile to set Environment / Lib path
Local system time: Mon Jan 1 01:04:29 GMT 2001
TM800@/]# hdparm -Tt /dev/sda
/dev/sda:
Timing buffer-cache reads: 36 MB in 0.53 seconds = 69480 kB/s
Timing buffered disk reads: 21 MB in 3.13 seconds = 6861 kB/s
TM800@/]#
also, CPU info from the same receiver
TM800@/]# cat /proc/cpuinfo
system type : NXP STB22x
processor : 0
cpu model : MIPS 4KEc V6.8
BogoMIPS : 397.31
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes
ASEs implemented : mips16
shadow register sets : 1
VCED exceptions : not available
VCEI exceptions : not available
TM800@/]#
will repeat the processor info on my older receiver later
PLi® openpli TM800
192.168.1.180 login: root
Password:
Running /etc/profile to set Environment / Lib path
Local system time: Mon Jan 1 01:04:29 GMT 2001
TM800@/]# hdparm -Tt /dev/sda
/dev/sda:
Timing buffer-cache reads: 36 MB in 0.53 seconds = 69480 kB/s
Timing buffered disk reads: 21 MB in 3.13 seconds = 6861 kB/s
TM800@/]#
also, CPU info from the same receiver
TM800@/]# cat /proc/cpuinfo
system type : NXP STB22x
processor : 0
cpu model : MIPS 4KEc V6.8
BogoMIPS : 397.31
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes
ASEs implemented : mips16
shadow register sets : 1
VCED exceptions : not available
VCEI exceptions : not available
TM800@/]#
will repeat the processor info on my older receiver later
Interesting, as well as sorting out the data bus the cpu is now clocked at a nominal 400Mhz (was BogoMIPS : 317.44) so I suspect originally someone loaded the wrong instructions in a UART.
That looks like nxp could be footing the bill!
That looks like nxp could be footing the bill!
try
then post the contents of /tmp/hdd.txt
ps got the network mount to work but still crashes with mkv file
,fine with .ts though.
Code:
You don't have permission to view the code content. Log in or register now.ps got the network mount to work but still crashes with mkv file
,fine with .ts though.
Last edited:
- Joined
- Aug 29, 2001
- Messages
- 41,824
- Reaction score
- 12,524
ps got the network mount to work but still crashes with mkv file
TM just rang me ellie and they are going to contact you to add it to next release if thats OK
Hi i am happy to see some real progress with the TM800 but could someone tell me what the HD info you are posting actualy means am I correct in thinking its the speed the processor can read the HD. Also will that comand work on my VU as it would be interesting to know what that is as a comparison.
Well I tryed it anyway hope it wont do anything to my box lol.
I dont know if this is usefull as a comparison as I said dont realy understand the information. But here is the same info from my VU.
/dev/sda:
Timing cached reads: 852 MB in 2.01 seconds = 424.76 MB/sec
Timing buffered disk reads: 86 MB in 3.07 seconds = 28.02 MB/sec
I dont know if this is usefull as a comparison as I said dont realy understand the information. But here is the same info from my VU.
/dev/sda:
Timing cached reads: 852 MB in 2.01 seconds = 424.76 MB/sec
Timing buffered disk reads: 86 MB in 3.07 seconds = 28.02 MB/sec
try it and see, the most you will get is a result or command unknown.
not a problem but still have to mount on a reboot, will look at automating in but last time I tried I bricked the box, don't have a backup image so will wait for that facility 1st then will play.
have sent them the info so they can still add it for the people willing to enter the mount cmd in telnet.
HD info with the -Tt parameters measures the rate of data flow from the processor buffer to the disks own buffer. Modern hard disks have large data buffers and in a linux operating system it saves data writes and places them on the disk either when the buffer reaches a preset level of fullness or at a pre-set time interval, whichever comes first.
Sata disks can receive data at very high rates of either 1.5Ghb/sec or 3Ghb/sec which is far above the capability of the motherboard to deliver. So hdparm measures the rate the system can deliver data to the disk, not the rate the disk can receive.
The problem, now solved, that this box had was that the chipset on the motherboard was clearly not handling data fast enough to support the flow required for decrypting HD channels.
The fix has increased the maximum data flow rate tenfold and upped the cpu operating speed by 20%, apart from any other changes like better handshaking or signal recognition.
Sata disks can receive data at very high rates of either 1.5Ghb/sec or 3Ghb/sec which is far above the capability of the motherboard to deliver. So hdparm measures the rate the system can deliver data to the disk, not the rate the disk can receive.
The problem, now solved, that this box had was that the chipset on the motherboard was clearly not handling data fast enough to support the flow required for decrypting HD channels.
The fix has increased the maximum data flow rate tenfold and upped the cpu operating speed by 20%, apart from any other changes like better handshaking or signal recognition.
With a PC this seems obvious,
but with the TM's CPU running so much more efficiently, will this have a positive effect on the over heating issue?
So far these results are great news, thanks to everyone involved, I'm feeling a lot more positive about my TM returning home...
but with the TM's CPU running so much more efficiently, will this have a positive effect on the over heating issue?
So far these results are great news, thanks to everyone involved, I'm feeling a lot more positive about my TM returning home...
Actually the TM800HD is just a PC running a modified Linux distribution (Ubuntu) which is popular on Laptops. The nxp cpu is a mips processor which runs the reduced instruction set and at 400Mhz would be about equivalent to a 900Mhz x86 type processor. However the heat produced by the cpu increases with increasing speed. My guess is that a 20% increase in speed would cause about a 35% increase in temperature - when working at maximum throughput.
However the cpu only produces part of the heat in the box, just a little more than the disk when recording.
I would be inclined to ensure the box has plenty of circulation space.
However the cpu only produces part of the heat in the box, just a little more than the disk when recording.
I would be inclined to ensure the box has plenty of circulation space.
is it possible to factory reset the TM800 without booting fully into enigma ? i couldn't find any option when i killed mine.
something like the factory reset option the TM600 has in uboot.
Hmm not sure actualy i think i saw a post somewere that a member reset the box via miniweb?
Similar threads
