May contain traces of nut
About twice the time then (4 mins v 2 mins).
My command line requirement is met now with stripts. The only thing against stripts on Windows is the cygwin dependency. This is not an issue for me but I guess some people might not want to install it.Now that the Windows command line stripts is available can I take it that I needn't look into providing a Windows command line decryption utility - except for my own amusement?
Oops my bad, with the /B argument the files are still reported as identical. In either case (stripts or HFODU2) neither process consumed more than 6% of my CPU in task manager.Should the FC command have a /B argument to perform a binary comparison?
Wouldn't have expected twice the time. I did some comparisons a while ago with a numerical simulation code written by someone else in C (or maybe C++) and my code in Java and an old version in Fortran. I don't remember there being that much of a difference. Perhaps af123 writes better code than I do.You would expect it to be longer with all the Java overhead!
19:38:41 INFO: Processing 1 files. 19:38:41 INFO: Decrypting: C:\[deleted]\HFODU2\enc_Pointless.ts 19:38:53 INFO: The file was decrypted successfully. 19:38:53 INFO: Output is C:\[deleted]\enc_Pointless_dec.ts
For what it's worth, tunefix is developed/debugged in Visual Studio and the same C++ source code compiles on the T2 without change. Any platform differences are handled in (my own) class/function library code with #ifdef sections.I am still hoping (as he has not said no yet!) @af123 will be able to do a similar trick to produce a Windows/cygwin version of HMT
Ah yes I forgot about the log. FYI the actual timings are shown below. To my eye it finished at at 17:53 dead, so I don't know where the extra 36 seconds came from?-Rather than manually timing a slightly more accurate way would be to look in the log file
17:49:00 INFO: Processing 1 files. 17:49:00 INFO: Decrypting: E:\testing\The Desert Fox_20171229_1604.ts 17:53:36 INFO: The file was decrypted successfully. 17:53:36 INFO: Output is E:\testing\The Desert Fox_20171229_1604_hfodu.ts
Having given it a bit of thought there are quite a number of things that could cause the differences.I would have thought that the majority of the time was spent doing the 3Des decryption so maybe stripts has a better implementation of this algorithm?
Yep, not worth the candle. As far as I can see this is just a theoretical discussion about different implementations.I could experiment with hfodu to see if I can speed it up. But, as there now exists another method for offline decryption in Windows, is it worth it [rhetorical]?
All that matters is that should people with a Humax Fox-T2 need to decrypt off the box there are a couple of tools to do this.
I wouldn't think so. The OS allocates tasks to processors or virtual processors, unless the code is specifically written to launch another thread (which is then serviced by the OS according to available resources). Why would stripts be written with multi-threading in mind, when that's not available on the HDR-FOX processor/OS?I've no idea how stripts is implemented and whether it is possible that it could run multi-threaded.
Which is what I hoped. That doesn't mean that I don't find the longer execution time odd to say the least. I might look at it - but only for my own (spit) continued professional development.Yep, not worth the candle. As far as I can see this is just a theoretical discussion about different implementations.
I don't know and, since I don't have one, I didn't know.Why would stripts be written with multi-threading in mind, when that's not available on the HDR-FOX processor/OS?
But it is -- perhaps you were thinking of hyper-threading? The Linux/uClibc combination provided by Humax has the Native POSIX Threads library back-ported to uClibc (Humax version 0.9.29, NPTL appeared in 0.9.32) and the SoC features 2 CPUs, making threaded applications very worthwhile for Humax devs, even if the Opera browser components didn't need threading anyway:... Why would stripts be written with multi-threading in mind, when that's not available on the HDR-FOX processor/OS?
humaxhdr# top top - 01:37:01 up 14:22, 0 users, load average: 4.94, 3.21, 2.18 Tasks: 86 total, 4 running, 82 sleeping, 0 stopped, 0 zombie Cpu0 : 24.5%us, 36.9%sy, 35.3%ni, 0.0%id, 0.7%wa, 0.7%hi, 2.0%si, 0.0%st Cpu1 : 19.9%us, 43.1%sy, 35.9%ni, 0.3%id, 0.7%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 125016k total, 118952k used, 6064k free, 8868k buffers Swap: 131064k total, 204k used, 130860k free, 49728k cached ... humaxhdr# cat /proc/739/status Name: humaxtv State: S (sleeping) SleepAVG: 78% Tgid: 739 Pid: 739 PPid: 659 TracerPid: 0 Uid: 0 0 0 0 Gid: 0 0 0 0 FDSize: 256 Groups: VmPeak: 354940 kB VmSize: 76512 kB VmLck: 0 kB VmHWM: 46180 kB VmRSS: 44252 kB VmData: 40916 kB VmStk: 84 kB VmExe: 6292 kB VmLib: 26416 kB VmPTE: 356 kB Threads: 113 SigQ: 0/2048 humaxhdr#
stripts, however, is single threaded. It does read packets in chunks of 10,000 though which may explain some of the speed difference.