Ftp used 64k buffers for data connection

VERIFIED FIXED in mozilla1.0.1

Status

()

Core
Networking: FTP
P3
normal
VERIFIED FIXED
16 years ago
15 years ago

People

(Reporter: Suresh Duddi (gone), Assigned: Suresh Duddi (gone))

Tracking

({perf})

Trunk
mozilla1.0.1
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

16 years ago
Does ftp really need to use 64k buffers ?
(Assignee)

Comment 1

16 years ago
Darin suggested I try to dumb it down and see the effect. I tried 4k 16k and 64k
on both DSL (256kbps) and LAN (5Mbps). No difference. We can safely use 4k
buffers for this.
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.0.1
(Assignee)

Comment 2

16 years ago
Created attachment 84825 [details] [diff] [review]
4k buffers for data channel. Max 32k.

Comment 3

16 years ago
cc'ing FTP folks.

Comment 4

16 years ago
Comment on attachment 84825 [details] [diff] [review]
4k buffers for data channel. Max 32k.

sr=darin
Attachment #84825 - Flags: superreview+
Do we really want this? See bug 69836, which increased this originally.

Comment 6

16 years ago
bbaetz: actually, that bug was about the fact that we used to use 64 byte
segments with a 512 byte maximum.  it doesn't look like anyone tried 4k segments
or a maximum of a more reasonable size such as what DP is suggesting here. 
also, the patch in that bugs shows 32k segments, but the source reads 64k!!
Comment on attachment 84825 [details] [diff] [review]
4k buffers for data channel. Max 32k.

If theres no noticable perf difference, r=bbaetz
Attachment #84825 - Flags: review+
(Assignee)

Comment 8

16 years ago
checked into trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Updated

16 years ago
Keywords: perf, verifyme

Comment 9

15 years ago
VERIFIED as code change in lrx.
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.