Re: [opensource-dev] New HTTP Library & Project Viewer
I can't help but think something is wrong here. A single TCP/IP link is more than capable of saturating available network bandwidth with efficient transfers of large volumes of data provided the end-points can produce and consume quickly enough. It seems part of the problem may in the request/response nature of HTTP. The viewer needs to make a request for each asset it needs as it discovers it needs it. It sends a request for each asset, and the provider endpoint then has to do whatever it does to make the asset available before beginning to send it back to the client. This may occur relatively instantly in the case of assets in a server memory cache, or a lot longer depending on where it needs to be pulled from or how it may need to be prepared. Assuming this is the case, having multiple overlapping requests can improve the overall download rate of multiple assets by allowing some downloads to occur while others are prepared, albeit at the expense of additional connections. Having a persistent connection reduces some of the delays introduced by re-establishing a connection for each asset, but it does nothing to reduce the time that the server endpoint needs to acquire and prepare the asset to send. Now (assuming this isn't the case already) if the producer endpoint could be made aware of future requests, it could fetch and prepare the asset for transfer prior to the actual request being received, thereby reducing or eliminating the time delays inherent in the request-response paradigm. This *may* be as simple as adding additional optional UUIDs and parameters to the asset request for assets that the viewer would likely be requesting next. If this were the case, a single connection could have a higher effective throughput by ensuring minimal delays between request and response, and reduce the need for more simultaneous connections. Such a solution may or may not be practical or easily implemented in existing infrastructure, or may not be as efficient as other designs. My point is more or less meant to bring more perspectives into the discussion by considering other bottlenecks that may exist, which if mitigated, could reduce the need for excessive connections. Thoughts? -dahlia On Wed, Aug 1, 2012 at 7:22 AM, Monty Brandenberg wrote: > On 7/31/2012 10:03 PM, Kadah wrote: > > > Its 8 again with the fallow comment. I tired to track down the rev, > > but apparently Mecurial 2.2 can't properly annotate that file for some > > reason, and the new UI for it in TortoiseHg2 is horrid. All of the > > referenced jiras around its changes are not public. > > One of the major reasons around that has to do with the > behavior of low-end routers. It really is a problem for > them. > > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] New HTTP Library & Project Viewer
Wow. In excess of fourteen megabits per second of texture loading madness with greatly reduced rendering stalls. Didn't take long to fill up and hit discard bias of 5.0. Yes, we see some brief render stalls after that, but from a different cause, I think. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] New HTTP Library & Project Viewer
On Tue, 31 Jul 2012 19:03:09 -0700 Kadah wrote: Kadah, Please note that I cannot read your posts. They have no clear text in them, and exist only of a Microsoft(tm) company specific attachment. You might want to fix this. -- Carlo Wood ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] New HTTP Library & Project Viewer
Kadah's emails are signed with an ascii-armored pgp key (not microsoft). You can ignore the munged gobledy-gook key and find his messages somewhere in the middle. :) Sent from my android device. -Original Message- From: Carlo Wood To: opensource-dev@lists.secondlife.com Sent: Thu, 02 Aug 2012 10:57 AM Subject: Re: [opensource-dev] New HTTP Library & Project Viewer On Tue, 31 Jul 2012 19:03:09 -0700 Kadah wrote: Kadah, Please note that I cannot read your posts. They have no clear text in them, and exist only of a Microsoft(tm) company specific attachment. You might want to fix this. -- Carlo Wood ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] New HTTP Library & Project Viewer
On Thu, 2 Aug 2012 02:01:45 -0700 Dahlia Trimble wrote: > I can't help but think something is wrong here. A single TCP/IP link > is more than capable of saturating available network bandwidth with > efficient transfers of large volumes of data provided the end-points > can produce and consume quickly enough. > > It seems part of the problem may in the request/response nature of > HTTP. The viewer needs to make a request for each asset it needs as > it discovers it needs it. It sends a request for each asset, and the > provider endpoint then has to do whatever it does to make the asset > available before beginning to send it back to the client. This may > occur relatively instantly in the case of assets in a server memory > cache, or a lot longer depending on where it needs to be pulled from > or how it may need to be prepared. Assuming this is the case, having > multiple overlapping requests can improve the overall download rate > of multiple assets by allowing some downloads to occur while others > are prepared, albeit at the expense of additional connections. Having > a persistent connection reduces some of the delays introduced by > re-establishing a connection for each asset, but it does nothing to > reduce the time that the server endpoint needs to acquire and prepare > the asset to send. > > Now (assuming this isn't the case already) if the producer endpoint > could be made aware of future requests, it could fetch and prepare > the asset for transfer prior to the actual request being received, > thereby reducing or eliminating the time delays inherent in the > request-response paradigm. This *may* be as simple as adding > additional optional UUIDs and parameters to the asset request for > assets that the viewer would likely be requesting next. If this were > the case, a single connection could have a higher effective > throughput by ensuring minimal delays between request and response, > and reduce the need for more simultaneous connections. > > Such a solution may or may not be practical or easily implemented in > existing infrastructure, or may not be as efficient as other designs. > My point is more or less meant to bring more perspectives into the > discussion by considering other bottlenecks that may exist, which if > mitigated, could reduce the need for excessive connections. > > Thoughts? > -dahlia Dahlia, an overwhelming amount of past experience has taught us that Linden Lab is not interested if you "think along" with them about the server, or the viewer-server protocol,either with suggestions, designs or anything. This list is set up to get feedback about viewer bugs, and to announce things they came up with (in most cases someone else came up with than the ones that we're allowed to talk with). So, it's a complete waste of your time to do anything else than to just sit back and read what Linden Lab is going to push through (no matter what arguments you come with, or what flaws you point out). [ That being said, they came up with "pipelining" as the solution for the problem you mention. That allows a viewer to send new requests over the same connection, without having to wait for a reply for former requests. This isn't the most efficient solution, but a lot better (still depending on the closed source server implementation though) than how it works so far. ] -- Carlo Wood ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] New HTTP Library & Project Viewer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/2/2012 9:57 AM, Carlo Wood wrote:> Kadah, > Please note that I cannot read your posts. They have no clear text > in them, and exist only of a Microsoft(tm) company specific > attachment. > > You might want to fix this. I haven't used a MS email client since I quit my last job 6-7 years ago where it was required (Exchange). For personal emails, I've been using Thunderbird since version 1.0. :P On 8/2/2012 10:08 AM, cin...@cinderblocks.biz wrote: > Kadah's emails are signed with an ascii-armored pgp key (not > microsoft). You can ignore the munged gobledy-gook key and find > his messages somewhere in the middle. :) ^ Yeah, this. :3 I'm not sure what Carlo is seeing since the pgp signature block is at the end and says what it is in plaintext. :p -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQGtMwAAoJEIdLfPRu7qE2glgH/jFC5aCfgjaOlzJOYlfUI6Ng EY1BJs2KFxEporyAtj31lhdCSrzeuYmhCCVnxErZZytAwJjTWMfiu1k5gg9cx8Cc ZT51fj+qED3MDlcbAqthHmRdiIb3gTrhrgy8USaaQO8J+0nYAW3YDO8n4MEqV2Sr /rbcR5toOfo7kcW+uOES37umfiw+0mRSr+CeAGJfJGAmnKHNNEG0RH9CM36Hi1V4 rU72KNtD4T343HRmdW/WI4D89urA6B0H7K1TQ4uoeLN5fC1QSsaQ2qPz903y9oZX wCvdMxQxVMq03VZnvRWDF+ZDU+mhxv0qC9x+zfMGD90gdonagDN7eZQq/gseA60= =ZQ6T -END PGP SIGNATURE- ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] New HTTP Library & Project Viewer
Don't worry Carlo, I know better than to try to tell an engineer how to do her/his job ;) So, if pipelining is implemented and it works, what other bottlenecks are there that make multiple connections work so well? On Thu, Aug 2, 2012 at 10:14 AM, Carlo Wood wrote: > On Thu, 2 Aug 2012 02:01:45 -0700 > Dahlia Trimble wrote: > > > I can't help but think something is wrong here. A single TCP/IP link > > is more than capable of saturating available network bandwidth with > > efficient transfers of large volumes of data provided the end-points > > can produce and consume quickly enough. > > > > It seems part of the problem may in the request/response nature of > > HTTP. The viewer needs to make a request for each asset it needs as > > it discovers it needs it. It sends a request for each asset, and the > > provider endpoint then has to do whatever it does to make the asset > > available before beginning to send it back to the client. This may > > occur relatively instantly in the case of assets in a server memory > > cache, or a lot longer depending on where it needs to be pulled from > > or how it may need to be prepared. Assuming this is the case, having > > multiple overlapping requests can improve the overall download rate > > of multiple assets by allowing some downloads to occur while others > > are prepared, albeit at the expense of additional connections. Having > > a persistent connection reduces some of the delays introduced by > > re-establishing a connection for each asset, but it does nothing to > > reduce the time that the server endpoint needs to acquire and prepare > > the asset to send. > > > > Now (assuming this isn't the case already) if the producer endpoint > > could be made aware of future requests, it could fetch and prepare > > the asset for transfer prior to the actual request being received, > > thereby reducing or eliminating the time delays inherent in the > > request-response paradigm. This *may* be as simple as adding > > additional optional UUIDs and parameters to the asset request for > > assets that the viewer would likely be requesting next. If this were > > the case, a single connection could have a higher effective > > throughput by ensuring minimal delays between request and response, > > and reduce the need for more simultaneous connections. > > > > Such a solution may or may not be practical or easily implemented in > > existing infrastructure, or may not be as efficient as other designs. > > My point is more or less meant to bring more perspectives into the > > discussion by considering other bottlenecks that may exist, which if > > mitigated, could reduce the need for excessive connections. > > > > Thoughts? > > -dahlia > > Dahlia, an overwhelming amount of past experience has taught us that > Linden Lab is not interested if you "think along" with them about the > server, or the viewer-server protocol,either with suggestions, designs > or anything. This list is set up to get feedback about viewer bugs, and > to announce things they came up with (in most cases someone else came up > with than the ones that we're allowed to talk with). So, it's a complete > waste of your time to do anything else than to just sit back and read > what Linden Lab is going to push through (no matter what arguments you > come with, or what flaws you point out). > > [ That being said, they came up with "pipelining" as the solution for > the problem you mention. That allows a viewer to send new requests over > the same connection, without having to wait for a reply for former > requests. This isn't the most efficient solution, but a lot better > (still depending on the closed source server implementation though) > than how it works so far. ] > > -- > Carlo Wood > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
