Hi,
On 06/18/2013 10:33 AM, bigclouds wrote:
hi,all
i have used spice for a long time,it is good, but in pratice it needs
improvement, like resource usage, network bandwidth,performance.
1.it eats up much cpu on client side, up to 90% when play video. i am
sure whether decompression or something else uses so much cpu. if
client (remote-viewer) is corss-compiled to arm platform, what will
happen? iordan has succellful compiled it to android platform.
how to decrease cpu usage on client side?(if Mplayer which Fedor has
mention will help )
For improving video streaming cpu & network usage, it would be great to
have video pass-through and hardware accelerated decoding.
2.how to improve display effect and decrease network usage.
now glz algorithm seems the best, but display stuck, and mosaic (video
screen not sync) exist.
By default we use auto_glz. Quic is applied on images that are
classified as "real life" bitmaps. And GLZ is applied on images that are
artifical (e.g., mainly contain text).
better network leads to larger traffic, some time it goes up to 7M/s.
in future spice client will be often used in WAN , in that case the
less trafic the better.
guys , do you have some ideas?
Spice bandwidth usage is not deterministic, i.e., if you observe network
usage of 7M/s on LAN, it doesn't mean that spice-server will try to push
the same amount of data over WAN. Some of the bitmaps may be dropped if
possible.
For decreasing the bandwidth usage, you can think of features like
- improved caching (e.g., try to enlarge the cache size, and if it
helps, consider disk based caching).
- improved lossless compression (e.g., finding identical sub-regions
between bitmaps that are not necessarily "artificial" and compressed by
glz today; something like a combination of a dictionary-based encoding
and predictive encoding).
- Instead of setting TCP_NODELAY=0 over WAN (enabling Nagle's
algorithm), concatenate small messages in the application level (i.e.,
in spice server).Nagle's algorithm can lead to observed latencies due to
its interaction with the delayed ack timeout on the peer side (see
http://www.stuartcheshire.org/papers/NagleDelayedAck/)
Regards,
Yonit.
thanks
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel