| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
LLUDP client stack rather than queueing internally within LLClientView.
When an HG avatar enters a scene, it delays processing of entity updates. Could be crowding out by other updates or something else.
This delay in ones own av mvmt updates results in mvmt lag experienced on the client. Avoiding the internal LLClientView for these packets appears to resolve this issue.
Appears most noticeably for avatars with attachments, though has also been seen on those without sometimes. Hasn't been observed for non-HG avatars in general.
Will be investigating exactly what the problem is, at which point there will be a more permanent solution.
|
| |
|
|
| |
This allows one to set the requested throttle (which normally comes from the client) as opposed to the max.
|
| |
|
|
|
| |
On server, scene-throttle-max becomes max-scene-throttle and likewise max-new-client-throttle
On clients, throttle-max becomes max
|
| |
|
|
|
|
| |
client throttle to be set separately from existing clients.
"debug lludp throttles get/set throttle-max" now only gets and sets current max client throttles
|
| |
|
|
|
|
| |
to mirror "debug lludp set"
Information is also available in "show server throttles" but that's more for non-debug info rather than attempting to get and set parameters on the fly for debug purposes.
|
| |
|
|
|
|
|
|
|
|
| |
throttles would cause client throttles to be lower than expected when total requests exceeded the scene limit.
This was because specifying a max client throttle would always request the max from the parent server throttle, no matter the actual total requests on the client throttle.
This would lead to a lower server multiplier than expected.
This change also adds a 'target' column to the "show throttles" output that shows the target rate (as set by client) if adaptive throttles is active.
This commit also re-adds the functionality lost in recent 5c1a1458 to set a max client throttle when adaptive is active.
This commit also adds TestClientThrottlePerClientAndRegionLimited and TestClientThrottleAdaptiveNoLimit regression tests
|
| |
|
|
| |
make code analysis easier. No functional change.
|
| |
|
|
|
| |
This only had one child, which is the 'adaptive' token bucket.
So from testing and currently analysis, we can use that bucket directly which simplifies the code.
|
| |
|
|
| |
Renames to TestSingleClientThrottleRegionLimited()
|
| |
|
|
| |
behaviour of throttles where a region-wide total outbound limit is in place.
|
| | |
|
| |
|
|
| |
a max client total limit is enforced server-side
|
| |
|
|
|
|
| |
package rather than some in OpenSim.Tests.Common.Mock
the separate mock package was not useful and was just another using line to always add
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
OpenSim.Tests.Common.ClientStackHelpers
|
| |
|
|
| |
printing any information. Also fix max throttle displayed to be properly kbps
|
| |
|
|
| |
value is not set rather than 0
|
| |
|
|
|
|
| |
setting of default and existing client throttles.
Doesn't yet adjust until clients submit new throttle settings.
|
| |
|
|
|
|
| |
consistency (and because I keep typing throttles).
This will still work with "debug lludp throttle" anyway.
|
| |
|
|
| |
- throttle buckets are set in bytes, not bits
|
| |
|
|
| |
never applies.
|
| |
|
|
| |
which case they apply to all users in the lludp server
|
| | |
|
| | |
|
| |
|
|
| |
to potentially set the scene max throttle on the fly.
|
| |
|
|
|
|
| |
throttles" command rather than "show throttles"
THis allows us to see the rates when no client is connected to the region.
|
| |
|
|
|
|
|
| |
about throttles
This is separate from the user-oriented "show throttles" command since one will often only want to know about varying client throttle settings.
Currently displays max scene throttle and adaptive throttles config if set.
|
| |
|
|
|
|
| |
This is the total of queued outgoing packets across all connections, as also seen in the "show queues" command.
Gives some early indication of whether the simulator can't send all outgoing packets fast enough.
Though then one would want to check that this isn't due to a few bad client connections.
|
| | |
|
| | |
|
| |
|
|
| |
to match set command
|
| |
|
|
| |
Can currently only set adaptive true|false, where adaptive = false
|
| |
|
|
|
| |
Will only have any affect under Windows or mono with a patch such as https://gist.github.com/justincc/31e52218d098529b4696 (not recommended) applied.
For assessment purposes.
|
| |
|
|
| |
a client's throttle (currently just whether adaptive is enabled).
|
| |
|
|
| |
<avatar-last-name>" to control extra throttle related debug logging.
|
| |
|
|
|
|
|
| |
before it's put on the wire.
Unlike "debug lludp packet" which logs at the point where OpenSim first asks the clientstack to send a certain outgoing packet, this logs immediately before the actual send.
For low-level debugging purposes.
|
| |
|
|
|
|
| |
have shown that this has better scalability.
For testing, previous behaviour can be restored with the console command "debug lludp oqre stop" at runtime.
|
| |
|
|
|
|
|
|
| |
rather than a persistent thread with sleep.
This is to see if an inaccuracy in sleep times under load is responsible for increase in frame times even when there is spare time still available.
Can currently only be activated by setting "debug scene set update-on-timer true".
Can be switched between timer and thread with sleep updates whilst the scene is running.
|
| |
|
|
|
|
| |
inbound packets.
For test/debug purposes.
|
| |
|
|
|
|
|
| |
debug/test purposes.
This drops all outbound packets that match a given packet name.
Can currently only be applied to all connections in a scene.
|
| |
|
|
| |
Only present if OQRE is enabled
|
| |
|
|
|
|
|
|
|
|
|
| |
on a controlled number of threads rather than the threadpool.
Disabled by default. Currently can only be enabled with console "debug lludp oqre start" command, though this can be started and stopped whilst simulator is running.
When a connection requires packet queue refill processing (used to populate queues with entity updates, entity prop updates and image queue updates), this is done via Threadpool requests.
However, with a very high number of connections (e.g. 100 root + 300 child) a very large number of simultaneous requests may be causing performance issues.
This commit adds an experimental engine for processing these requests from a queue with a persistent thread instead.
Unlike inbound processing, there are no network requests in this processing that might hold the thread up for a long time.
Early implementation - currently only one thread which may (or may not) get overloaded with requests. Added for testing purposes.
|
| |
|
|
|
|
|
| |
protected so that other logging code in the clientstack can record more useful information
Adds some commented out logging for use again in the future.
No functional change.
|
| |
|
|
| |
closed on teleport, don't unnecessarily resend all avatar and object data about that region.
|
| |
|
|
|
|
| |
neighbour) don't resend all the initial avatar and object data again.
This is unnecessary since it has been received (and data continues to be received) in the existing child connection.
|
| |
|
|
| |
actually meant to get an ack (because it's reliable).
|
| |
|
|
| |
main assets server. Also, some cleanup.
|
| |
|
|
| |
is being throttled due to past poor performance.
|
