The scripts assume that the sessions are under
~/rfbsessions.turbo.hiqual. If they aren't, then edit the script or
move the sessions accordingly.
If that doesn't work, you may also want to rename them without a .txt
extension and chmod 700 on them so you can run them directly. Perhaps
running them with 'bash {script}' is causing problems, although it would
be a first in my experience if so.
On 10/14/12 6:31 PM, James Wettenhall wrote:
> DRC,
>
> OK, I finally have a bit more time to play around with this stuff.
>
> I have downloaded the session files and the attached scripts, and I have
> installed LibreOffice so that I can open the vncviewer.ods spreadsheet.
>
> Now I'm trying to run the "vncviewerbench.txt" script, e.g. using
> bash vncviewerbench.txt
>
> but I get an error:
> Testing bugzilla-16.rfb ...
> Could not open session capture: No such file or directory
>
> Am I missing something obvious?
>
> Cheers,
> James
>
>
> On 05/10/2012, at 7:45 AM, DRC wrote:
>
>> OK, here's the scoop:
>>
>> (1) Download the session files from:
>>
>> https://docs.google.com/folder/d/0B-KUeGuQMxsjVERKVGtCS2Y3MXc/edit
>> (Filename: rfbsessions.turbo.hiqual.tar.bz2)
>>
>> (2) Untar into your home directory.
>>
>> (3) Install the latest X11 viewer package for Mac (but note that this
>> procedure works with the Linux packages as well.)
>>
>> (4) Use the attached scripts to run the sessions through the TurboVNC
>> Viewer. Redirect the output to a file.
>> -- Make sure that you have shut down as many applications as you
>> can and that you don't try to do anything with the system while
>> running the benchmarks.
>> -- Your display resolution needs to be 1280x1024 or larger.
>>
>> (5) Use the attached parse_output script to extract the decoding,
>> blitting, and total time and copy/paste them into the attached
>> spreadsheet template
>> ('parse_output {output file} -d|-b|-t' extracts decode, blit, and
>> total time, respectively.)
>>
>>
>> How to recreate these session files:
>>
>> The sessions were created using the TurboVNC Benchmark Tools:
>>
>> svn co
>> https://virtualgl.svn.sourceforge.net/svnroot/virtualgl/vncbenchtools/trunk
>> vncbenchtools
>>
>> and the original, uncompressed set of session captures (that were
>> obtained via rfbproxy some years ago.) The original session captures
>> are described in detail in this report:
>> http://www.virtualgl.org/pmwiki/uploads/About/tighttoturbo.pdf. I am
>> in the process of uploading them to the same Google Drive folder (the
>> link to which is in (1) above) under the name rfbsessions.tar.bz2.
>>
>> cd vncbenchtools
>> mkdir {my_build_directory}
>> cd {my_build_directory}
>> cmake -DENCODER=turbo-1.1 -DDECODER=turbo-1.0 ..
>> make
>>
>> Now you can run
>>
>> ./compare-encodings -{depth} -to [-rgb] {input_file} -o {output_file}
>>
>> where {depth} is 16 or 24, depending on the depth of the session (the
>> filename indicates which) and -rgb specifies that the session used RGB
>> component ordering (needed only for googleearth and q3demo.)
>>
>> The default settings in the encoder use the Tight + Perceptually
>> Lossless JPEG encoding method, but this can be changed by editing
>> vncbenchtools/turbo-1.1.c, changing
>> compressLevel/qualityLevel/subsampLevel, and rebuilding.
>>
>>
>> Let me know if you encounter any problems.
>>
>> On 10/3/12 4:51 PM, James Wettenhall wrote:
>>> DRC,
>>>
>>> I'm happy to help with Mac OS X performance testing if you send me
>>> instructions. I think your proposal to remove the X11 binary from the
>>> Mac distribution sounds reasonable for future releases, but you're not
>>> suggesting removing it from the 1.2 release are you? I would have to
>>> change my code, because if it can't find /opt/TurboVNC/bin/vncviewer,
>>> then it assumes that TurboVNC viewer has not been installed. (On
>>> Windows, my code checks the registry.)
>>>
>>> Cheers,
>>> James
>>>
>>> Sent from my iPhone
>>>
>>> On 04/10/2012, at 3:28 AM, DRC <dcomman...@users.sourceforge.net
>>> <mailto:dcomman...@users.sourceforge.net>> wrote:
>>>
>>>> I guess I had been assuming that the X11 viewer was faster on Mac in the
>>>> aggregate because it was faster on Linux and because the smaller 2D
>>>> datasets I happened to be using for quick & dirty benchmarks were faster
>>>> with X11 than with Java on Mac. However, I hadn't actually done a full
>>>> benchmarking shootout on that platform until now. I just did the full
>>>> comparison of all 20 "canonical" 2D and 3D datasets, comparing the
>>>> latest Java viewer code with the X11 viewer running in XQuartz 2.7.4 as
>>>> well as in XQuartz 2.3.6 (the version that shipped with OS X 10.6.)
>>>> This was done both on my 64-bit 2009 vintage Mac Mini as well as my
>>>> 32-bit 2006 vintage Macbook, and the results were surprising. On both
>>>> platforms, the decoder was slower in Java, as expected (25% slower on
>>>> both platforms, vs. native.) However, the drawing was so slow in
>>>> XQuartz that the Java viewer managed to pull ahead and finish about 15%
>>>> faster on the Mac Mini and 27% faster on the Macbook, relative to the
>>>> X11 viewer running in XQuartz 2.7.4. Relative to the older XQuartz that
>>>> Apple used to ship, the Java viewer was 32% faster on the Mac Mini and
>>>> 65% faster on the Macbook.
>>>>
>>>> I'd be really interested to see if any other Mac users can duplicate
>>>> these findings, particularly on a higher-end Mac (the Mini has a GeForce
>>>> in it, but still not a Mac Pro by any means.) I'll be glad to send you
>>>> my benchmark datasets and instructions on how to run them and collect
>>>> the data. If these findings continue to bear out, then it would be
>>>> worth considering dropping the X11 viewer from Mac altogether, so if
>>>> there are any strong objections to that, I'd be interested to hear those
>>>> as well. I mean, it will always be possible to build it from source.
>>>> The idea is that I would just not package the X11 viewer as a binary on
>>>> that platform anymore, and the Java viewer would be the documented
>>>> solution for Mac.
>>>>
>>>> There is one major feature that the Java viewer lacks, which is keyboard
>>>> grabbing support, but in fact, that feature doesn't work on Mac with the
>>>> X11 viewer, either, and it's less critical on Mac, because the
>>>> keystrokes that one typically needs to grab (Alt-Tab, Ctrl-Esc, Windows
>>>> and Menu keys, etc.) aren't captured by the operating system. Thus, I
>>>> think that, in general, it might be a perfectly reasonable thing to just
>>>> ship the Java viewer. Yeah, OS X 10.7 doesn't include Java by default,
>>>> but neither does it include an X server by default.
>>>>
>>>> DRC
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Don't let slow site performance ruin your business. Deploy New Relic APM
>>>> Deploy New Relic app performance management and know exactly
>>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>>> http://p.sf.net/sfu/newrelic-dev2dev
>>>> _______________________________________________
>>>> VirtualGL-Devel mailing list
>>>> VirtualGL-Devel@lists.sourceforge.net
>>>> <mailto:VirtualGL-Devel@lists.sourceforge.net>
>>>> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Don't let slow site performance ruin your business. Deploy New Relic APM
>>> Deploy New Relic app performance management and know exactly
>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>> http://p.sf.net/sfu/newrelic-dev2dev
>>> _______________________________________________
>>> VirtualGL-Devel mailing list
>>> VirtualGL-Devel@lists.sourceforge.net
>>> <mailto:VirtualGL-Devel@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
>>>
>> <vncviewerbench.txt><vncviewerbench.java><parse_output.txt><vncviewer.ods>------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev_______________________________________________
>> VirtualGL-Devel mailing list
>> VirtualGL-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>
>
>
> _______________________________________________
> VirtualGL-Devel mailing list
> VirtualGL-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
>
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
VirtualGL-Devel mailing list
VirtualGL-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
