Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[hoyt]

This is a fairly open ended question I think, and certainly may be answered by trial and error on my part...

I recently rebuilt the server that I have which runs the VM for JRiver.  I changed from running Lubuntu 14.04 32 Bit to Lubuntu 16.04 64 bit.  I then dropped 24 GB of memory in the machine because I could now allocate >3.5GB to one VM.  I built a new VM for JRiver while I was at it on Win10 64bit.  I allocated 2 CPU cores (I think they're i5 EA3450s @ 3.0 GHz) and 8 GB of memory.  I have 4 or 5 other VMs on this server, but they all run Lubuntu and are very lightweight (1 CPU + 500MB - 1GB of RAM).

One of the reasons I went through this exercise was that I had a heck of a time transcoding on the fly JTV files to watch via JRemote on my LAN.  Previously I had 2 cores, but only 2 GB of memory running on a VM of Win7 32bit.  Transcoding a 3 hour JTV recording was taking in the neighborhood of 12 - 16 hours.  I haven't tried this yet, and probably won't get a chance to until later this week.  But I was curious if there were general guidelines for what type of JMark is "good enough" to handle that?  I can likely up the memory and CPU cores to the VM, but since I have other stuff on the server, would prefer to keep it at the needed level and not overkill it.

Thanks!

[RoderickGI]

Yes, that is a very open ended question! 

It really depends so much on what you are transcoding from and to.

The PC in my signature which has a JMark of about 4555 can transcode 15Mbps 720x576 PAL video @ 25 fps with MPEG2 stereo audio @ 256Kbps to the MC MPEG2-TS 720p PAL, AC-3 stereo 48KHz, 192Kbps format with absolutely no problems playing live video on my workstation MC Client. I have lots of other stuff running on the MC Server at the moment, and it still isn't an issue. I think MC is using about 7% CPU once playback stabilises, after a peak of around 50% at startup of the video, and total MC memory usage is just 200MB.

Transcoding an 80Mbps 1440x1080i PAL video @25 fps with AC-3 6 channel audio @ 448Kbps to the MC MPEG2-TS 720p PAL, AC-3 stereo 48KHz, 192Kbps format with absolutely no problems playing live video on my workstation MC Client. The CPU peaked higher at startup, over 55%, then settled to about 15% average, but with a lot of variation. Memory usage grew to about 850MB after starting lower.

Upping the transcode to MPEG2-TS 1080p increase CPU to around 35%, with memory pretty much unchanged.

Upping the transcode to H264-TS 1080p sees the CPU maxed out, running at over 90% CPU with 105% CPU speed (turbo mode), with memory at around 450MB.

So, you are just going to have to test your environment and see what happens. But 2 cores and 8GB of memory sounds like it should be enough, as long as you aren't trying to transcode to the highest H264 format.

[hoyt]

Thanks for the response.  Took me a while to get back to this, but I just ran my benchmarks and was surprised to see that it wasn't much better than win7 with just one processor and 2 GB of memory...

Code: [Select]

=== Running Benchmarks (please do not interrupt) ===

Running 'Math' benchmark...
    Single-threaded integer math... 4.212 seconds
    Single-threaded floating point math... 2.449 seconds
    Multi-threaded integer math... 4.197 seconds
    Multi-threaded mixed math... 2.453 seconds
Score: 1427

Running 'Image' benchmark...
    Image creation / destruction... 1.720 seconds
    Flood filling... 3.128 seconds
    Direct copying... 4.067 seconds
    Small renders... 1.997 seconds
    Bilinear rendering... 3.033 seconds
    Bicubic rendering... 2.267 seconds
Score: 1357

Running 'Database' benchmark...
    Create database... 0.445 seconds
    Populate database... 3.377 seconds
    Save database... 0.961 seconds
    Reload database... 0.217 seconds
    Search database... 5.227 seconds
    Sort database... 1.842 seconds
    Group database... 1.379 seconds
Score: 1599

JRMark (version 21.0.76): 1461
I'll have to actually try to transcode something later to see how long it takes, but that doesn't make me feel too confident.

[mwillems]

Memory isn't really the rate-limiting factor in JRiver transcoding for a few reasons, CPU grunt is much more important.  One reason that memory isn't pressing is that JRiver is a 32-bit program and can't use more than 2GB itself in any case, and another is that I've seen virtually no correlation of memory available to JRMark or transcoding performance provided that the system isn't actively swapping.  My JRiver VM server has about 3GB of memory, and the JRmark is identical to what it was when I ran it at 2GB, and the transcoding performance is about the same.  Unless you're swapping, memory pressure isn't really a factor.

CPU power is much more important to transcoding performance, and there more cores usually helps unless you're getting close to the number of actual physical cores in the system.  For example, my server runs on an Intel i7 4790S.  It has 4 physical cores and 4 logical cores.  Assigning two cores to the JRiver VM improved performance.  Assigning a third core also improved performance.  Assigning a fourth core actually reduced performance!  Assigning further cores reduced performance even further.  The virtualization solution I use (virtualbox) warns against assigning "more" CPUs than you have physical cores, but in my own testing even assigning "as many" cores as you have is slower than assigning n-1.  You mentioned an i5, but didn't mention how many cores you have, but if it's a dual physical core i5 (with 2 additional logical cores) then you may be running into this issue.  i5's are also missing some of the advanced virtualization features that i7's get as well as I recall.

For context, my server VM (3 cores of an i7 4790S with 3GB RAM) has a JRMark around 4000.  It can handle live transcoding for any content I've tried.  For some content it can handle multiple simultaneous transcodes (2 is usually not a problem, 3 is dicey).

[hoyt]

Yes, I'm running virtualbox as well.  The server I have has 2 physical cores, each with 4 virtual cores inside.  Something must be up with what I did before then because with 2 cores on Win7 32bit with 2 GB of RAM, I remember trying to transcode a 4 hour baseball game and it took a full day (>24 hours).

Trying with a JTV file now from an hour long episode of TV on a 720p channel (so 3.5 GB):
- to mp4, 720 auto, it gets to 2% after 3+ minutes and my CPU usage is 90%+.
- to mp4, 720, CPU is similar but it gets to 2% in about 1.5 minutes.
- to MPEG2-720 PAL, CPU is around 70% and it gets through 2% in under a minute.

[RoderickGI]

Our processors are very similar, with the major differences being you are running just two cores in your VM, and I have a HD4000 iGPU, while you have a HD2500. See http://ark.intel.com/compare/65520,65511

For comparison, my JRiver Benchmark with all four cores is;

=== Running Benchmarks (please do not interrupt) ===

Running 'Math' benchmark...
    Single-threaded integer math... 3.737 seconds
    Single-threaded floating point math... 2.488 seconds
    Multi-threaded integer math... 1.908 seconds
    Multi-threaded mixed math... 1.288 seconds
Score: 2017

Running 'Image' benchmark...
    Image creation / destruction... 0.175 seconds
    Flood filling... 0.395 seconds
    Direct copying... 0.479 seconds
    Small renders... 1.262 seconds
    Bilinear rendering... 0.884 seconds
    Bicubic rendering... 0.553 seconds
Score: 5871

Running 'Database' benchmark...
    Create database... 0.195 seconds
    Populate database... 0.957 seconds
    Save database... 0.120 seconds
    Reload database... 0.077 seconds
    Search database... 1.029 seconds
    Sort database... 1.353 seconds
    Group database... 0.709 seconds
Score: 4842

JRMark (version 21.0.76): 4243

Mine -> Yours
Math 2017 -> 1427
Image 5871 -> 1357
Database 4842 -> 1599
Overall 4243 -> 1461

Big differences.

Are you sure your cores aren't being throttled?
How is the iGPU shared in he VM?

[hoyt]

Are you sure your cores aren't being throttled?

I have the processors set to 100% cap execution, so shouldn't be any throttling. 

How is the iGPU shared in he VM?

I'm guessing that's the issue...  I hadn't really thought of expanding the GPU capabilities of this server because it doesn't directly serve any video.  So it uses the motherboard's base VGA output.  I have it set to the max (128 MB of memory).  I just tried setting it to use 3D rendering, and increasing to 256 MB, but it seems to have made very little difference in the benchmark scores. 

Would that have such a drastic effect? 

Are you running an SSD base drive by chance?  I was wondering how that would help me with the database figures.  I was surprised to see my database tests so far out of line.

[mwillems]

I have the processors set to 100% cap execution, so shouldn't be any throttling. 

I'm guessing that's the issue...  I hadn't really thought of expanding the GPU capabilities of this server because it doesn't directly serve any video.  So it uses the motherboard's base VGA output.  I have it set to the max (128 MB of memory).  I just tried setting it to use 3D rendering, and increasing to 256 MB, but it seems to have made very little difference in the benchmark scores. 

Would that have such a drastic effect? 

Are you running an SSD base drive by chance?  I was wondering how that would help me with the database figures.  I was surprised to see my database tests so far out of line.

I can confirm from firsthand experience that SSDs make a huge impact on JRMark's (worth about a thousand points on one of my installs).  Whether that actually translates to transcoding performance is anyone's guess.

[RoderickGI]

Are you running an SSD base drive by chance?  I was wondering how that would help me with the database figures.  I was surprised to see my database tests so far out of line.

Yes, I run an SSD for the Windows OS. But all media is on spinning hard disks in the HTPC/MC Server, so while that may improve the JMark score, I don't think it would improve me transcoding situation over yours. It is the Image benchmark that shows your problem.

A GPU with good hardware acceleration would probably assist with the transcoded/conversion issue most, after more CPU power.

[hoyt]

The SSD question was an aside of this I guess.  Just popped in my head because I had considered getting an SSD for the OS while rebuilding the main server, but decided instead to just use a 500GB drive I had laying around.

I'm wondering now if I have GPU issues in the main server OS (lubuntu).  I don't do any real video stuff on it so I hadn't noticed, but there does seem to be some lag when dragging windows around the screen - even with the CPU at rock bottom %s.  That shouldn't be happening.  That must be driving the Image score way low.  I'll have to figure that out in the linux side I presume.  It may be easier to just order a new GPU that's separate from the CPU.

Thanks for the advice - this may take a bit of work to get sorted!  I'll try to keep this thread updated if I figure something out (or just give up and add a GPU card).

[blgentry]

I seem to recall that the image benchmark under Linux is sort of broken and is something like 10x as slow as the corresponding image benchmark under windows.

Brian.

[mwillems]

I seem to recall that the image benchmark under Linux is sort of broken and is something like 10x as slow as the corresponding image benchmark under windows.

Brian.

This is true, but humorously windows guest VMs on Linux hosts don't have the issue.  I find it hilarious that my windows VM guest has a better JRMark than the baremetal Linux system hosting it