I am developing the application in which every things depends on internet.my Requirement is that when the speed of internet is low,app should display alert to user that "your internet speed is low, that's why this feature is not available to you."
I want to know that is there any feature available in ios from which we can know that our internet connection is low or speed of internet, I have found 2-3 answers about this but not get any feasible solution.
There is no magic call to know whether the Internet connection is fast or slow. There's only one solution - transfer data and time how long it takes to transfer a certain amount of data.
The problem is that the next chunk of data can be much slower, much faster, or about the same.
So you really need some sort of threshold where if the app is unable to transfer at least X number of bytes in Y seconds, then you stop the transfer and alert the user.
In other words, there's no simple way to ask "Is the connection fast or slow?".
Related
I need to realize a source-synchronous receiver in a Virtex 6 that receives data and a clock from a high speed ADC.
For the SERDES Module I need two clocks, that are basically the incoming clock, buffered by BUFIO and BUFR (recommended). I hope my picture makes the situation clear.
Clock distribution
My problem is, that I have some IOBs, that cannot be reached by the BUFIO because they are in a different, not adjacent clock region.
A friend recommended using the MMCM and connecting the output to a BUFG, which can reach all IOBs.
Is this a good idea? Can't I connect my LVDS clock buffer directly to a BUFG, without using the MMCM before?
My knowledge about FPGA Architecture and clocking regions is still very limited, so it would be nice if anybody has some good ideas, wise words or has maybe worked out a solution to a similar problem in the past.
It is quite common to use a MMCM for external inputs, if only to cleanup the signal and realize some other nice features (like 90/180/270 degree phase shift for quad-data rate sampling).
With the 7-series they introduced the multi-region clock buffer (BUFMR) that might help you here. Xilinx has published a nice answer record on which clock buffer to use when: 7 Series FPGA Design Assistant - Details on using different clocking buffers
I think your friends suggestion is correct.
Also check this application note for some suggestions: LVDS Source Synchronous 7:1
Serialization and Deserialization Using
Clock Multiplication
I would like to synchronize (within .05 seconds) an event in the future on more than one iOS device, whether or not those devices have network access at that future time.
To do this, I believe I'll need to sync to a common clock between these devices, and the best way would be to get a precise time from an NTP server(s). I've looked at iOS-NTP, but the description says that that it determines time with 1 second accuracy, and that doesn't quite do it for me.
One alternative is to get the (accurate?) timestamp from a GPS clock, but I'm not sure that the devices will always have the ability to get a GPS signal.
Any other suggestions?
iOS doesn't give you low level access to the GPS hardware, so you can't use that method.
If the devices are close to each other, you can establish a peer to peer wireless connection using GameKit. That should give you around 35ms latency with bluetooth, and the latency should be consistent so you could measure it a few times to get the clocks in sync.
If they're not close together... then I would setup a server and use that as the "real" time. With several calls you should be able to measure the latency between the device and the server, then calculate the clock offset with reasonable accuracy.
If possible use UDP instead of TCP, that way network congestion will drop packets instead of delaying them.
You'll need to keep on re-calculating the offset though, since iOS devices change their clock frequently (I think it's part of the 3G/LTE network protocol? Jumping from one cell tower to another might update the clock).
I would like to know if it's still necessary to throttle the bandwidth when transferring multiples large files (PDF) over the cellular network.
There is no information about this in the guidelines but some old threads points out this was necessary.
http://forums.macrumors.com/archive/index.php/t-1130677.html
iPhone app rejected for "transferring excessive volumes of data"
Thanks in advance.
I believe this only applies for streaming like mp3 data.
If you have a large single file which you need to download, throttling the bandwidth is an especially bad idea. The opposite would be recommend: download as fast as possible in order to safe battery and increase reliability of the connection (the shorter the duration the less the probability that it gets interrupted).
You should however check whether the connection uses the cellular network and notify the User and ask whether your app should defer the download when Wifi is available, possibly automatically in the background without starting the app. This approach is feasible (utilizing NSURLSession).
We have a critical need to lower the latency of our UDP listener on iOS.
We're implementing an alternative to RTP-MIDI that runs on iOS but relies on a simple UDP server to receive MIDI data. The problem we're having is that RTP-MIDI is able receive and process messages around 20ms faster than our simple UDP server on iOS.
We wrote 3 different code bases in order to try and eliminate the possibility that something else in the code was causing the unacceptable delays. In the end we concluded that there is a lag between time when the iPAD actually receives a packet and when that packet is actually presented to our application for reading.
We measured this with with a scope. We put a pulse on one of the probes from the sending device every time it sent a Note-On command. We put another probe attached to the audio output of the ipad. We triggered on the pulse and measured the amount of time it took to hear the audio. The resulting timing was a reliable average of 45ms with a minimum of 38 and maximum around 53 in rare situations.
We did the exact same test with RTP-MIDI (a far more verbose protocol) and it was 20ms faster. The best hunch I have is that, being part of CoreMIDI, RTPMIDI could possibly be getting higher priority than our app, but simply acknowledging this doesn't help us. We really need to figure out how fix this. We want our app to be just as fast, if not faster, than RTPMIDI and I think this should be theoretically possible since our protocol will not be as messy. We've declared RTPMIDI to be unacceptable for our application due to the poor design of its journal system.
The 3 code bases that were tested were:
Objective-C implementation derived from the PGMidi example which would forward data received on UDP verbatim via virtual midi ports to GarageBand etc.
Objective-C source base written by an experienced audio engine developer with a built-in low-latency sine wave generator for output.
Unity3D application with Mono-based UDP listener and built-in sound-font synthesizer plugns.
All 3 implementations showed identical measurements on the scope test.
Any insights on how we can get our messages faster would be greatly appreciated.
NEWER INFORMATION in the search for answers:
I was digging around for answers, and I found this question which seems to suggest that iOS might respond more quickly if the communication were TCP instead of UDP. This would take some effort to test on our part because our embedded system lacks TCP capabilities, only UDP. I am curious as to whether maybe I could hold open a TCP connection for the sole purpose of keeping the Wifi responsive. Crazy Idea? I dunno. Has anyone tried this? I need this to be as real-time as possible.
Answering my own question here:
In order to keep the UDP latency down, it turns out, all I had to do was to make sure the Wifi doesn't go silent for more than 150ms (or so). The exact timing requirements are unknown to me at this time, however the initial tests I was running were with packets 500ms apart and that was too long. When I increased the packet rate to 1 every 150ms, the UDP latency was on par with RTPMIDI giving us total lag time of around 18ms average (vs. 45ms) using the same techniques I described in the original question. This was on par with our RTPMIDI measurements.
Is it possible to bounce data back and forwards between lets say a USA computer and an Australian computer through the internet and just send these packets back and forwards and use this bounced data as a data storage?
As I understand it would take some time for the data to go from A to B, lets say 100 milliseconds, then therefore the data in transfer could be considered to be data in storage. If both nodes had a good bandwidth and free bandwidth, could data be stored in this transmission space? - by bounce the data back and forwards in a loop.
Would there be any reasons why this would not work.
The idea comes from a different idea I had some time ago where I thought you could store data in empty space by shooting laser pulse between two satellites a few light minutes apart. In the light minutes of space between then you could store data in this empty space as the transmission of data.
Would there be any reasons why this would not work.
Lost packets. Although some protocols (like TCP) have means to prevent packet loss, it involves the sender re-sending lost packets as needed. That means each node must still keep a copy of the data available to send it again (or the protocol might fail), so you'd still be using local storage while the communication does not complete.
If you took any networking classes, you would know the End-to-End principle, which states
The end-to-end principle states that application-specific functions ought to reside in the end hosts of a network rather than in intermediary nodes
Hence, you can not expect routers between your two hosts to keep the data for you. They have to freedom to discard it at anytime (or they themselves may crash at any time with your data in their buffer).
For more, you can read this wiki link:
End-to-End principle
It think this should actually work as in reality you store that information in various IO buffers of the numerous routers, switches and network cards. However the amount of storable information would probably be too small to have practical use, and network administrators of all levels are unlikely to enjoy and support such a creative approach.
Storing information in the delay line is a known approach and has been used to build memory devices in the past. However the past methods rely on delay during signal propagation over physical medium. As Internet mostly uses wires and electromagnetic waves that travel with the sound of light, not much information can be stored this way. Past memory devices mostly used sound waves.