[PATCH]] gatchat: improve large file Downlink data transfer
Fix large file Downlink data transfer on IFX modem. Increase buffer size of ring buffer to support close received Packets from the Modem Set highest priority for write data on tun device --- gatchat/gatio.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/gatchat/gatio.c b/gatchat/gatio.c index 9cfc998..9d44a78 100644 --- a/gatchat/gatio.c +++ b/gatchat/gatio.c @@ -197,7 +197,7 @@ static GAtIO *create_io(GIOChannel *channel, GIOFlags flags) io->use_write_watch = FALSE; } - io->buf = ring_buffer_new(4096); + io->buf = ring_buffer_new(8192); if (!io->buf) goto error; @@ -288,7 +288,7 @@ gboolean g_at_io_set_write_handler(GAtIO *io, GAtIOWriteFunc write_handler, if (io->use_write_watch == TRUE) io->write_watch = g_io_add_watch_full(io->channel, - G_PRIORITY_DEFAULT, + G_PRIORITY_HIGH, G_IO_OUT | G_IO_HUP | G_IO_ERR | G_IO_NVAL, can_write_data, io, write_watcher_destroy_notify); -- 1.6.6.1 - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH] Fix IFX large file Downlink data transer
--- gatchat/gatio.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/gatchat/gatio.c b/gatchat/gatio.c index 9cfc998..9d44a78 100644 --- a/gatchat/gatio.c +++ b/gatchat/gatio.c @@ -197,7 +197,7 @@ static GAtIO *create_io(GIOChannel *channel, GIOFlags flags) io->use_write_watch = FALSE; } - io->buf = ring_buffer_new(4096); + io->buf = ring_buffer_new(8192); if (!io->buf) goto error; @@ -288,7 +288,7 @@ gboolean g_at_io_set_write_handler(GAtIO *io, GAtIOWriteFunc write_handler, if (io->use_write_watch == TRUE) io->write_watch = g_io_add_watch_full(io->channel, - G_PRIORITY_DEFAULT, +G_PRIORITY_HIGH, G_IO_OUT | G_IO_HUP | G_IO_ERR | G_IO_NVAL, can_write_data, io, write_watcher_destroy_notify); -- 1.6.6.1 - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Segmentation fault on Downlink data transfer
Hi Denis, > What is the exact setup that you're using? Are you using GAtMux or the > kernel mux? Actually the mux was the internal to oFono, Kernel MUX is planned for further versions. > Can you check whether using synchronous writes to the TUN device fix your > problem? E.g. in new_bytes of gatrawip.c. Changing priority from G_PRIORITY_NORMAL to G_PRIORITY_HIGH avoid the issue of ring buffer overflow. However the ring buffer usage is at 2/3. This mean that 2 packets of 1420 are stored. A 3 one crash the system. In Mobile data transfer, it is often the cases that latency of packets can be much more greater that in wired network (RLC layer in Modem buffers incoming packet to reassemble its and deliver packet in right order of reception). In this case, several packet can be delivered by the Modem in burst. If another packet are to closed, we get a new ring buffer overflow. This is why I believe that this buffer need to be increase to avoid this situation. Taking some logs (tcpdump, ofono and internal Modem logs) show that burst of packets often occurs. So to Fix this issue 2 actions is required: - Set the G_PRIORITY_HIGH instead of NORMAL in g_io_add_watch_full in g_io_set_write_handler function (avoid to change mechanism to synchronous mode) - Secure the ring buffer overflow increasing the size (for example to 7100: capacity to store 5 Packets of 1420 bytes seems enough). > For the dlc disconnection after a ring buffer overflow, I continue to suggest > to change the behavior. At the end user side, a shutdown of the Modem is not > the solution. There is not a Modem issue and all others functionalities of > the Modem not need to be deactivate (ongoing Call drop if ongoing, No > Emergency Call available during reinitialisation, etc ...) Give me your feedback for the fix and tell me If you want me to submit a patch with this proposition. Regards Carlos - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Segmentation fault on Downlink data transfer
Hi Marcel and Denis There is an issue on downlink data transfer on ifx modem. Basically, during a data transfer after PDP context activation (long data transfer 5MB), a segmentation fault error could occurs at any time (even it is not systematic). GLib-CRITICAL **: g_io_channel_write_chars: assertion `channel != NULL' failed Root cause of this issue is a ring buffer overflow (in gatio received data function). The overflow is detected and the DLC3 source context is destroyed in dispatch source function. After that the disconnect handler is called and try to destroyed the same context. So on this issue there is 2 points: 1- Management of the buffer overflow 2- Buffer overflow cause For the 1st point, I'm not sure that disconnect DLC channel is the solution in case of buffer overflow. I believe that is better to discard ongoing packet in the buffer. TCP could survived to packet loss and retransmit the packets. Throughput go down but the data pipe is not broken for the application. For the 2nd point, ring buffer overflow happened because data is not consume in this buffer. This is a flow control problem. I suspect that for some reason the consumer is blocked (not schedule) during some time. Ring buffer size is set to 4096 bytes. I realize some test with a ring buffer increase to 131072 bytes and I can get long file downlink transfer. Probably this size is too much high and this size buffer need to be tune. Could you please give me feedback for this 2 points? This issue is very similar to bug track in: http://bugs.meego.com/show_bug.cgi?id=11700 Regards Carlos - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Call Barring and MMI Supplementary Service codes
Hi Rajesh,
> What values are expected from MMI services 25, 24 and 26?
> For MMI 22 (All Sync Services)=> 80 ("All data circuit sync" (16) + "All
> dedicated packet access" (64))
> For MMI 21 (All Async Services)=> 160 ("All data circuit async" (32) +
> "All dedicated PAD access" (128)).
> For MMI 26 (Telephony and All sync services)=> 81 (Telephony (1) + "All
> data circuit sync" (16) + "All dedicated packet access" (64))
> For MMI 24 (All data circuit sync)=> 16 ("All data circuit sync")
> For MMI 25 (All data circuit async)=> 32 ("All data circuit async")
I confirm your analyze for translation between MMI code services and classx
parameters for CLCK AT command.
Assuming that dedicated packet access is an synchronous services and dedicated
PAD access is an asynchronous services (2204-491, replaced by 2204)
MMI group oFono current translate table
10 [1 to 6,12] BEARER_CLASS_VOICE | BEARER_CLASS_FAX |
BEARER_CLASS_SMS1 + 4 + 8 OK
11 [1] BEARER_CLASS_VOICE
1 OK
12 [2 to 6 ] BEARER_CLASS_SMS | BEARER_CLASS_FAX
4 + 8 OK
13 [6] BEARER_CLASS_FAX
4 OK
16 [2] BEARER_CLASS_SMS
8 OK
19 [1, 3 to 6, 12] BEARER_CLASS_VOICE | BEARER_CLASS_FAX
1 + 4 OK
20 [7 to 11 ] BEARER_CLASS_DATA_ASYNC | BEARER_CLASS_DATA_SYNC
16 + 32 to be replace by 16 + 32 + 64 + 128
21 [7] BEARER_CLASS_DATA_ASYNC
32 to be replace by32 + 128
22 [8] BEARER_CLASS_DATA_SYNC
16 to be replace by16 + 64
24 [8] BEARER_CLASS_DATA_SYNC
16 OK
25 [7] BEARER_CLASS_DATA_ASYNC
32 OK
26 [1,8 ] BEARER_CLASS_VOICE | BEARER_CLASS_DATA_SYNC
1 + 16 to be replace by 1 + 16+ 64
I suggest to introduce you proposal on MMI 21, 22, 26 and also add changes on
MMI 20
Regards
Carlos
-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
