Am Mittwoch, 31. Juli 2013, 10:56:45 schrieb Kadah:
a transparent squid proxy, with SL specific cache re-write scripts, makes a
massive difference
two questions...
- does it still have to be a transparent squid, now that the viewer actually
has proxy settings?
- do you still have those
On 8/1/2013 12:23 AM, Lance Corrimal wrote:
- does it still have to be a transparent squid, now that the viewer actually
has proxy settings?
Sorry, I didn't mean transparent. I have a transparent one at work on
one network for other reasons. Setting the web proxy in viewer is all
that's needed.
Additionally to that, the amount of traffic that goes through the actual
sim these days has been highly reduced with bringing textures, mesh and
materials onto the sim-external HTTP pipeline that isn't bound to a single
sim.
Of course there is still people who feverishly set their texture
Am Dienstag, 30. Juli 2013, 17:28:50 schrieb Darien Caldwell:
Considering at high speeds, 12 sims worth of data can be downloaded in 1-2
minutes (which is a ridiculous worst case scenario, but happens since LL
won't realistically limit draw distances),
Not completely unrelated: I visited a LEA
I had transfers set to UDP for a long time aswell because HTTP was just way
slower, caused my router alot of problems and often also prevented my
Avatar from ever rezzing in any SIM, same for some other Avatars.
2013/7/31 Lance Corrimal lance.corri...@eregion.de
Am Dienstag, 30. Juli 2013,
I have made full sim art installations myself and i do think the platform
of SL should be able to handle such a thing as it has a totally different
feel then a 50x50 meter setup with a backdrop, one can use shadows and fog
to give it a real nice atmosphere. A solution to the bandwidth problem and
The idea is actually very nice, i should take a look at limiting bandwidth
to your current SIM only at times.
2013/7/31 Marx Catteneo marxcatte...@gmail.com
I have made full sim art installations myself and i do think the platform
of SL should be able to handle such a thing as it has a
On 7/30/2013 11:39 PM, Ambrosia wrote:
Additionally to that, the amount of traffic that goes through the
actual sim these days has been highly reduced with bringing
textures, mesh and materials onto the sim-external HTTP pipeline
that isn't bound to a single sim.
CAPs are per sim host I
On 7/31/2013 1:09 AM, Marx Catteneo wrote:
PS as a machinimator i need the fastest possible connection to the
servers because any throttling can give me a stuttering image, so if i
turn mine down i'll have to wait an hour before i can start filming in a
sim and even then it would stutter more
Names or it didn't happen.
2013/7/30 Kadah kadah.c...@gmail.com
On 7/26/2013 10:47 AM, Argent wrote:
On Jul 26, 2013 12:32 PM, Darien Caldwell darien.caldw...@gmail.com
mailto:darien.caldw...@gmail.com wrote:
So basically while this system is probably beneficial to those with
bad
Well, since everyone has to download the same amount of data
in the end, its rather hard to use a disproportional amount
of resources, unless a viewer just downloads the SAME thing
over and over again, which would be severe bug.
The only other thing that might be called using too much
resources
On 7/30/2013 8:25 AM, Carlo Wood wrote:
Well, since everyone has to download the same amount of data
in the end, its rather hard to use a disproportional amount
of resources, unless a viewer just downloads the SAME thing
over and over again, which would be severe bug.
The only other thing
Problem with your example is, you assume the % of bandwidth is constant. If
downloading data was a constant 40% or 4%, I would agree. But SL is a very
bursty service. Once you have the data for the scene, it uses very, very
little bandwidth at all. So all of that bandwidth is not being utilized
On 7/26/2013 10:47 AM, Argent wrote:
On Jul 26, 2013 12:32 PM, Darien Caldwell darien.caldw...@gmail.com
mailto:darien.caldw...@gmail.com wrote:
So basically while this system is probably beneficial to those with
bad internet connections, it's rather punitive to those who have
excellent,
Hi all,
I'm not quite clear about the ThrottleBandwidthKBPS debug setting... the
sources suggest the value is understood as kilobit per second, but the name of
the debug setting itself suggests kiloBYTE per second. Which one is it?
...and is it even still relevant with most traffic being
On Fri, 26 Jul 2013 11:04:25 +0200, Lance Corrimal wrote:
Hi all,
I'm not quite clear about the ThrottleBandwidthKBPS debug setting... the
sources suggest the value is understood as kilobit per second, but the name
of
the debug setting itself suggests kiloBYTE per second. Which one is
On Fri, 26 Jul 2013 13:58:47 +0200
Henri Beauchamp sl...@free.fr wrote:
This setting is indeed only relevant to UDP traffic, or at least in
LL's and most TPV viewers. IIRC, I saw attempts to account for this
limit with HTTP texture fetching traffic in Singularity, but that
would need to be
My Viewer has:
ThrottleBandwidthKBPS
which also clearly says this:
Maximum allowable downstream bandwidth (kilo bits per second)
then theres also this:
XferThrottle
Maximum allowable downstream bandwidth for asset transfers (bits per second)
so i guess asset and everything else is also split, at
There has to be some other throttle, because ThrottlebandwidthKBPS seems to
correspond to what you set your bandwidth to in preferences (max 10,000
with LL's viewer).
However, This is being capped by the servers:
2013-07-26T16:46:00Z INFO: LLViewerThrottleGroup::sendToSim: Sending
throttle
3000? thats double the amount i would have assumed it is capped at.
and yes, the Debug is obviously the preferences setting.
2013/7/26 Darien Caldwell darien.caldw...@gmail.com
There has to be some other throttle, because ThrottlebandwidthKBPS seems
to correspond to what you set your
The same amount of data has to be sent either way. Seems to me it would be
more beneficial to the servers to get requests out of the way faster to
free up the pipe for other requests. Dragging it out as long as possible is
only going to clog the pipe longer.
On Fri, Jul 26, 2013 at 10:47 AM,
21 matches
Mail list logo
