Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Non-Tech : Quote.com QCharts -- Ignore unavailable to you. Want to Upgrade?

To: jebj who wrote (9555)	9/27/2000 11:03:27 AM
From: HairBall	Respond to of 17977

To All: This discussion on users using to much bandwidth is JUST PLAIN BUNK. Quote.Com is responsible to provide its customers timely reliable service based on the service offered at the price offered. A contract is a contract... If users are using more bandwidth increase the infrastructure to handle it...IT REALLY IS JUST THAT SIMPLE! If usage per customer increases to a point where it makes sense to increase prices...raise them. However, the service should be running like a fine tuned Swiss time piece first... However, it would seem to me since Quote.Com can offer unlimited java charts for free...the price for this service is not to low...<g> Regards, LG

To: jebj who wrote (9555)	9/28/2000 1:16:36 AM
From: pooh	Read Replies (1) \| Respond to of 17977

Hi jebj, I don't think the user's modem rate would worsen the response of the server. The server would careless what kind of modem speed the user has. In realtime application, the program doesn't usually require the hand-shaking process. The server just sends the data, and assumes that the user will receive them. This is how it works: the server from Qchart allows a certain amount of time for each request-for-data from the user. If the user requests too much data, which may takes more than the allowable time to response, then the server suspends the process at the allowable time, and goes on to the next user. It would resume the process to the specific user once it's done with the other "waiting for response" users. Based on such logic, it's the amount of the requested data and not the speed of the user's modem that affects the server. For example, if there are x amount of users (say x = 100) on a specific server, the server would provide an equally allowable time for each user, say 10 milliseconds each. If the user has a small workspace, then the server only needs 5 ms to respond instead of 10 ms, before it goes to the next user. If the user has a large workspace, which is requesting a large amount of data, the server allows up to 10 ms then suspends the process to go to the next user. The large workspace user would have to wait up to 990 ms before the server resume the process to respond to his large request. Note that the numbers are assumed. If quote.com use an 80286 Intel chip on the server, the number would have to be different!!! What if the user opens more than one window? Now, that WILL slow down the response from the server. If one user opens 100 windows (workspaces), then the server would look at it as if there are 100 users open one window each. It would careless who (username) requests the data. It just knows that channel xyz requests such data, so it sends them through that channel. In order to speed up the process, quote.com will need to add more servers to minimize the number of requests per server. Of course, the bottle neck is still the 128K feed that quote.com receive the data from. However, don't confuse that with the rate of request from users and the rate of response from the servers. At a moderate rate-of-trade on the market, 128K may not be too bad. But if on a moderate rate-of-trade day, and the data crash, it's the quote.com's problem. On the "black" Friday, I suspect it's the quote.com's problem: the programmer forgot to put an error flag when the number of trades on INTC exceeds its memory allocation. How does that sound? pooh