• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

how can I know bandwidth

 
ying qu
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi:
I'm implementing a midlet under J2ME Wireless Toolkit. I want to know how many bit/second the current network-connection bandwidth is in my application, how can I get this data with Java? Is there anybody know the answer?
Thanks a lot!!
Ying
 
Michael Yuan
author
Ranch Hand
Posts: 1427
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I guess I have to ask, why do you want to know this? The wireless toolkit uses your host PC's internet connection. The network performance on real devices could be very different. I do not see how that information can be useful.
If you really really want to do it, you can just download a large file using your MIDlet and use a MIDP Timer object to time it ...
 
Rishi Tyagi
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Michael Yuan,
I agree with you that in general we don't need this.
But if we want to download some fix amount of data and want to tell the user that how much time it will take to download data and also wnat to show the progress on the screen in this case we may need the same.
I would also like to know if there is any method available in j2men for the above and will be highly obliged if anybody can help on the same.
Regards,
Rishi
 
Sayed Ibrahim Hashimi
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't know your answer but, you might have to specify wether you want to know the max bandwidth (ie 100mb/s) or at what rate a file is downloading because those are two different questions.
 
Michael Yuan
author
Ranch Hand
Posts: 1427
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Rishi Tyagi:
Michael Yuan,
I agree with you that in general we don't need this.
But if we want to download some fix amount of data and want to tell the user that how much time it will take to download data and also wnat to show the progress on the screen in this case we may need the same.

Well, no method can reliabllly predict the download time. The connection might be dropped the next second.
If you want to show a progress bar and give educated guess on how long the remaining of the doanload should take, you can just do what we always do in the J2SE world:
Get the total size from the HTTP header;
Keep record on how much data has been read;
Show the percentage bar;
Keep record on how much time has lapsed;
calculate the estimated remaining time.
 
Mark Herschberg
Sheriff
Posts: 6037
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Michael Yuan:
I guess I have to ask, why do you want to know this? The wireless toolkit uses your host PC's internet connection. The network performance on real devices could be very different. I do not see how that information can be useful.

Because it may effect what choices the user makes. At the microscopic level, there's the estimated download time ("hmm... I don't really want to wait 10 minutes to download this app, I'll do it when I get home"). At the macroscopic level, the user may engage in a task which requires heavy bandwidth use, or may choose to hold off on starting that task until another time.
My experience has suggested that bandwidth is often the most constrained resource on wireless devices. Memory and speed, while limited, are fixed. Bandwidth is limited, and occasionally even more so, and sometimes altogether gone.
--Mark
 
Byron Estes
Ranch Hand
Posts: 313
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you wanted to "guesstimate" the time remaining (knowing full well that the guesstimate will change constantly), couldn't you...
While you are looping periodically take note of the time and the amount of data downloaded. By comparing the times and amounts you should be able to get a throughput value (...some amount of data per some amount of time), that can be divided into the remaining data to get an estimate based upon the last "time periods" thoroughput.
Obviously, this could bounce around alot so you might want to use multiple time periods to reduce volatility. It might be simple average or one which weights more recent timings higher than others.
Regards,
 
Michael Yuan
author
Ranch Hand
Posts: 1427
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mark Herschberg:

My experience has suggested that bandwidth is often the most constrained resource on wireless devices. Memory and speed, while limited, are fixed. Bandwidth is limited, and occasionally even more so, and sometimes altogether gone.

Hi Mark,
If bandwidth is so unstable and can be "altogether gone", it makes even less sense to predict download time based on historical data. Right?
 
Mark Herschberg
Sheriff
Posts: 6037
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Michael Yuan:

If bandwidth is so unstable and can be "altogether gone", it makes even less sense to predict download time based on historical data. Right?

Obviously you can't always know when a network will necessarily go down, or when your train might go through a tunnel. However, the network is more unstable over "long" periods, but relatively stable over "short" periods. By this I mean, if you are downloading a file at a certain rate, it's unlikely in the next 20 seconds the rate will differ much.
On the other hand, physical location (strong or weak signal, building in the way), weather, and network load vary both during the day and from day to day.
--Mark
 
Stefan Haustein
Author
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, some kind of progress bar would at least help the user to determine whether the application is still downloading or already crashed, even if it is not very reliable. However, for this purpose it is probably necessary that the download takes place in a separate thread, otherwise it may block the display: Some devices do not show screen updates until the command handler returns.... (and according to the MIDP spec the commandAction() method should return immediately)
Best,
Stefan
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic