89 replies to this topic

[anudanan]

On  my VU+ uno 4K SE the MovieCut Plugin is sometimes slow and cuts 1-2 Mbyte/s and sometimes 20-30Mbyte/s.

 

In the past on my ET8000 it was allways fast (10-30 Mbyte/s).

 

I know th ET8000 has a mips core and the uno 4Kse has an ARM Core

 

Is it possible that the moviecut Plugin has problems with performance on an ARM core?

 

Or maybe there is a problem during I/O to the HDD. The uno 4kSE has an internal 2,5 HDD 2TB (Seagate Baracuda) and the et8000 has a Samsung HD204UI (2TB)

 

Is the HDD performance inside the uno 4k SE better when I install a FireCuda Hybrid HDD instead of the Baracuda HDD to speedup HDD operations? Maybe the operation of Block Allocation is faster then?

 

Or is there an I/O Bug inside the Kernel on which openpli 6.1RC works

Edited by anudanan, 27 December 2017 - 12:49.

[MiLo]

Is it possible that the moviecut Plugin has problems with performance on an ARM core?

No

Or maybe there is a problem during I/O to the HDD. The uno 4kSE has an internal 2,5 HDD 2TB (Seagate Baracuda) and the et8000 has a Samsung HD204UI (2TB)

No

Is the HDD performance inside the uno 4k SE better when I install a FireCuda Hybrid HDD instead of the Baracuda HDD to speedup HDD operations? Maybe the operation of Block Allocation is faster then?

No

Or is there an I/O Bug inside the Kernel on which openpli 6.1RC works

No


Maybe there's some filesystem corruption on your harddisk?

[anudanan]

I´ve made an fsck.ext4 but no errors found

I´ve made tune2fs -l /dev/sda1 and on my  other boxes I´ve done it also with the HDDs there

 

I see one difference between the Filesystem flags

 

all older HDDs in my boxes hat

Filesystem flags:         signed_directory_hash

 

the 2,5 inch Seagate Baracuda in  bei uno 4kSE has

Filesystem flags:         unsigned_directory_hash

 

I´ve made the filesystem on it with openpli 6.1 RC1. The  filesystems of the other HDDs in the other boxes I´ve made with openpli 4.x

 

I know the difference between signed and unsigned but what means that in this filesystem flags?

Is that a problem?

 

 

 

[anudanan]

Is it possible that it has to do with the bug around the used and free space which the commands du and df show different after some file read, file write and file remove?

 

There is a german thread around that

 

https://forums.openp...ei-pli6-stable/

 

I´ve tested a workaround with the mount option nodelalloc but after that I have some interrupts in my recorded movies when I cut and move movies in parallel to the recording process.

[MiLo]

Well, "nodelalloc" basically reverts to ext3 behaviour so that'd have some serious impact on performance.

I have an old 1.5TB disk that reports a "signed" hash, I converted this from ext3 to ext4 about 7 years ago. It still has 4k clusters as a result, but it never showed any problem.

You might want to try exchanging disks and see if the problem is the disk or the box. Just trying random "solutions" from the internet isn't likely to work.

[Erik Slagter]

Start with hdparm -t to check the raw disk access speed.

Edited by Erik Slagter, 28 December 2017 - 11:44.

[betacentauri]

I think the ext4 bug (the one that causes different values for disk usage when you look at df and du) itself don't cause any performance problems.
Is your hard disk quite full? Maybe the blocks from the file are spread all over the disks so that it has to seek for every block.

[anudanan]

Today the disk speed seems to be ok. Actual during cutting movies the new file grows up nearls 30Mbyte/s (the means 30Mbyte/s read, 30 Mbyte/s write). Some parallel recording movies are also write data to the hdd

The disk has nearly 600GByte free.

 

My wife is a poweruser and does at the same time

- movies cutting on the HDD,

- movies moving from the same HDD to NAS drives

- and recording new movies to the same HDD (4-6 movies from the central box uno4K-SE and 4-5 movies from the remote box uno4K-SE)

 

It seems that moving movies from the HDD to the NAS makes interrupts in the new recorded movies.

 

On my old et8000 I used a USB Ethernetadapter because the internal Ethernat has linkdown/up problems. The network speed was poor but with that box I havén´t no interrupts during moving movies to the NAS. My idea behind that is the et8000 can´t move the movie so fast to the NAS so the box has enough free CPUspeed and diskspeed to record movies without interrupt.

 

Is it possible that moving movies to the NAS consumes to much HDD and CPU power when it works with Gbit/s (my et8000 mit USB can´t do that speed)

 

Is it possible to give the recorded processes more priority than the moving jobs, which uses the linux mv command

 

 

Do you think an newer linux kernel can do it better? I´ve seen that VTI uses kernel 4.1 but I like openpli until today

Edited by anudanan, 28 December 2017 - 12:35.

[anudanan]

I´ll test the diskspeed tomorrow, because today the box is busy 

[betacentauri]

You can use try to use the "nice" command(so "nice -n19 mv ...") . But I'm not sure whether this helps as it seems it only set priority for CPU usage and not IO usage.

[anudanan]

hdparm -t with the HDD shows 130MByte/s

 

that must be fast enough

Edited by anudanan, 29 December 2017 - 07:07.

[MiLo]

Is it possible to give the recorded processes more priority than the moving jobs, which uses the linux mv command

The recording threads already run in high priority, so that effort is already spent. You can be more nice using "ionice" but that doesn't actually work these days since even harddisks have large queues and buffers these days. Even a nice process will fill these buffers in mere milliseconds, and other processes will still have to wait for that queue to be processed before they get any attention, regardless of their priority.

With the 4.14 kernel and BFQ scheduler this will probably improve a lot.

[Erik Slagter]

But the notion that with a newer kernel disk I/O go sky high is going to be a disappointment. If that were the case, no single cloud server could be running a Linux kernel before 4.14.

 

Historically Linux has always been more efficient than Windows at accessing hard disks (though nowadays the difference will be minimal). So you really can't blame Linux.

[anudanan]

I think I´ve found the main reason. I´ve installed the plugin EnhancedMovieCenter because I like some feature of it

- I can see on my main boxe also the record state of movies which remote boxes store on the main box HDD. That is nice

- I can mark more than one movie to do some actions with them for example moving to other directories (do the integrated player has that?)

- you can see the movies in the movielist which are moved to other locations (NAS)  with a special symbol (for example -->). That is nice.

- you can see which movies execute the cutting 

- some shortcuts with the remote control

 

But I´ve learned now that plugin is the reason for the above problems. 

 

Now I must discuss it with my wife what we do. 

 

One idea is to test the VTI Image and the embedded player there. I don´t know his featureset

Edited by anudanan, 29 December 2017 - 12:09.

[MiLo]

I have even seen plugins that do stupid things like forcibly flush the filecache every few seconds, and it would not surprise me if the EMC plugin has adopted some of these "fixes".

[MiLo]

But the notion that with a newer kernel disk I/O go sky high is going to be a disappointment. If that were the case, no single cloud server could be running a Linux kernel before 4.14.
 
Historically Linux has always been more efficient than Windows at accessing hard disks (though nowadays the difference will be minimal). So you really can't blame Linux.

It won't matter much for I/O speed, and it will probably not even make a difference in (synthetic) benchmarks.

The trouble with Linux I/O system is that it (almost immediately) loses track of which process an I/O operation belongs when it has reached the file cache subsystem (which is what actually moves data to/from disk in Linux). This quickly leads to starvation, since one process can easily hog the whole IO subsystem.

On any linux system to date, if you launch a few "tar" operations that read large portions of the disk(s), the system usually slows down to a crawl because the "tar" processes hog all IO resources and other processes have difficulty getting through. The huge hardware buffers these days only make that worse, it's buffer-bloat for I/O and not just networks these days...

The BFQ scheduler keeps track of the owner processes of the IO requests, and distributes the IO time more evenly. It costs extra CPU time (and a bit of memory) to do this, so on most benchmarks, the BFQ will perform a bit below CFQ. But on a desktop system, this makes a huge difference, as the system remains responsive no matter how much IO other processes are using.

For Enigma2 this will make a huge difference. The recording threads generate very little I/O, delivering usually less than 1MB/s of data. But when there's a file-copy or so in process, the file output will stall for a long time waiting for I/O bandwidth. Currently this is being compensated for by have several megabytes of extra buffering in E2 code for each recording thread, and using overlapped IO. The BFQ scheduler will reduce the average latency even in those extreme cases to mere milliseconds, thus making chances of overruns virtually zero under heavy load - provided that the disk has enough bandwidth to cope with the reccordings, but at the data rates required for recording that's usually of no concern.

The BFQ scheduler is actually available for older kernel versions as a patch of sorts, so you can try it on your own machine if you really want to test it in real life.

[Erik Slagter]

Still I don't think exactly this is the "problem" here.

[WanWizard]

I had a quick glance at the code of EMC, it replaces half Enigma and plugins. So when one talks about EMC and MovieCut, it is not the MovieCut plugin, but the functionality built into EMC.

 

I also see a long list of event timers, and code that scans recordings to determine length based on timestamps, not sure what that is all about, as this info is in the meta data.

[anudanan]

I´ve made some tests during the last days with my uno4kse box to found out the reason for poor HDD performance during recording movies, cutting movies and moving movies to other NAS systems

 

I´ve deinstalled the EMC for  the tests and used the internal movielist to have no interdependeny with EMC.

I use a very old small EMC v1.1.0 which uses the MovieCut plugin for cutting, uses linux mv command for moving and uses the normal movieplayer for watching movies. My wife an I like that plugin because it uses different ICONs  for local and remote recordings (a remote box makes a record on the hdd in the local box). It marks movies which are in moving to other locations. I marks movies which are running MovieCut.

 

But for the firsts test the EMC is not involved.

 

My tests consists of 12 parallel recordings, a parallel job of moviecut for existing movies and a parallel moving job for moving movie to a NAS system. The hdd was half full (1TB from 2TB)

It doesn´t matter if I use openpli 6.1 or VTI 13.x with a newer kernel. When I make all this things with the internal 2TB hdd I ´ve interrupts inside the recorded movies and the cutting and moving performance is very bad.. 

In parallel I run a small shell script to see how many MByte the hdd can write during that test.

 

while true

do

df -m /dev/sda1

sleep 1

done

 

I see by using the internal hdd sometimes 30-40Mbyte/s write performance but sometime the hdd writes only 3-10 MByte/s. (rember the HDD must also read movie files)

The reaction rate of the enigma GUI during the tests is very poor. 

I uses also the VTI image with the hdd which I ´ve formated with openpli and 256K cluster. 

I can´t see any performance advantage by using VTI .

After that I´ve formated the HDD with VTI, they don´t use the big alloc. They use normal 4K blocks. But the test results are nearly the same.The performance is poor and the recorded movies have interrupts.

 

After that I go back to openpli 6.1 and run the test with the 4K block HDD. But also the performance was poor

 

Then I switched the hdd setup and used a USB 3.0 external HDD (2TB Samsung HD204UI (3,5 inch) inside a seagate housing)

The test result was interesting. The performance with the external hdd was much better. I haven´t seen interrupt in the movies and the cutting and moving performance was much higher as with the internal HDD. The write performance was between 30-70 Mbyte/s and I can´t see any stalled situation.

 

I´v the feeling that the driver for the  internal SATA interface  stalled sometimes and the result is a bad I/O performance. An other reason for that can be the different hdd performance, but I think that is not the reason because both HDDs are 5400er 2TB drives. I´will test that in some days with a external 2,5 inch housing for the 2,5 hdd. 

 

After all tests I´ve installed the old EMC on the openpli 6.1 and now the performance with the external drive is ok and much better than with the internal hdd. So the old EMC is not the reason for the bad performance.

 

In some days when I´ll make tests with the external 2,5inch HDD I will have a clear picture if the SATA driver  or the hdd causes the performance problem

 

Who has written the driver for the SATA interface inside the BCM7252S. The VU+ team or came it from the open source community?

[WanWizard]

Everything related to the SoC is part of the Broadcom SDK, and therefore part of the closed source driver. I doubt VU+ has done anything with it, other than just include the SDK driver.