When does the TCP engine decide to send an ACK?Finding cause of TCP retransmission within a LANUpload speed spikes: tries to increate to 100% and then falls back againIs a low-bandwidth arp-scan potentially disruptive to persistent TCP connections on the same LAN?Looking for advice to find the bottleneck of Samba serverWhy data sending is heavier for CPU than data receiving?Needs help to understand the wireshark results of a data transferringRoot cause behind increase in throughputlinux: upload / download difference on network sharesUbuntu server domain controller samba transfer speedsIs RST, ACK expected in a TCP Health Check
Should I decline this job offer that requires relocating to an area with high cost of living?
Adjacent DEM color matching in QGIS
Where is the documentation for this ex command?
What was the first story to feature the plot "the monsters were human all along"?
Nominativ or Akkusativ
Building a list of products from the elements in another list
Can there be a single technologically advanced nation, in a continent full of non-technologically advanced nations?
Point of the Dothraki's attack in GoT S8E3?
Shutter speed -vs- effective image stabilisation
Can my company stop me from working overtime?
Pressure inside an infinite ocean?
Has a commercial or military jet bi-plane ever been manufactured?
US born but as a child of foreign diplomat
How to write a 12-bar blues melody
Does it make sense for a function to return an rvalue reference?
Where in Bitcoin Core does it do X?
Do I add my skill check modifier to the roll of 15 granted by Glibness?
Why does this derived table improve performance?
Why did the Apollo 13 crew extend the LM landing gear?
Should I mention being denied entry to UK due to a confusion in my Visa and Ticket bookings?
What is a smasher?
Can my 2 children 10 and 12 Travel to the USA on expired American Passports? They are US citizens
Why are UK Bank Holidays on Mondays?
What is the solution to this metapuzzle from a university puzzling column?
When does the TCP engine decide to send an ACK?
Finding cause of TCP retransmission within a LANUpload speed spikes: tries to increate to 100% and then falls back againIs a low-bandwidth arp-scan potentially disruptive to persistent TCP connections on the same LAN?Looking for advice to find the bottleneck of Samba serverWhy data sending is heavier for CPU than data receiving?Needs help to understand the wireshark results of a data transferringRoot cause behind increase in throughputlinux: upload / download difference on network sharesUbuntu server domain controller samba transfer speedsIs RST, ACK expected in a TCP Health Check
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
In my LAN, I have a router that runs a Samba server and my PC connects to the router.
I wiresharked during a uploading to the server and a downloading from the server.
The wireshark results show that:
- During the uploading, the server sends an ACK every 0.6ms average
- During the downloading, my PC send an ACK every 0.025ms average
As a consequence, the downloading generates about 120,000 frames while the uploading only generates 70,000 frames. And the downloading rate is about 12.7Mbytes/s while the uploading rate is 20Mbytes/s.
So I want to figure out the possible reason for this.
linux networking samba tcp file-transfer
add a comment |
In my LAN, I have a router that runs a Samba server and my PC connects to the router.
I wiresharked during a uploading to the server and a downloading from the server.
The wireshark results show that:
- During the uploading, the server sends an ACK every 0.6ms average
- During the downloading, my PC send an ACK every 0.025ms average
As a consequence, the downloading generates about 120,000 frames while the uploading only generates 70,000 frames. And the downloading rate is about 12.7Mbytes/s while the uploading rate is 20Mbytes/s.
So I want to figure out the possible reason for this.
linux networking samba tcp file-transfer
A number of things could be determining this, switch performance and buffer sizes, disk capabilities on either end.
– SpacemanSpiff
Jan 10 '12 at 23:00
The reason for what?
– mailq
Jan 10 '12 at 23:01
add a comment |
In my LAN, I have a router that runs a Samba server and my PC connects to the router.
I wiresharked during a uploading to the server and a downloading from the server.
The wireshark results show that:
- During the uploading, the server sends an ACK every 0.6ms average
- During the downloading, my PC send an ACK every 0.025ms average
As a consequence, the downloading generates about 120,000 frames while the uploading only generates 70,000 frames. And the downloading rate is about 12.7Mbytes/s while the uploading rate is 20Mbytes/s.
So I want to figure out the possible reason for this.
linux networking samba tcp file-transfer
In my LAN, I have a router that runs a Samba server and my PC connects to the router.
I wiresharked during a uploading to the server and a downloading from the server.
The wireshark results show that:
- During the uploading, the server sends an ACK every 0.6ms average
- During the downloading, my PC send an ACK every 0.025ms average
As a consequence, the downloading generates about 120,000 frames while the uploading only generates 70,000 frames. And the downloading rate is about 12.7Mbytes/s while the uploading rate is 20Mbytes/s.
So I want to figure out the possible reason for this.
linux networking samba tcp file-transfer
linux networking samba tcp file-transfer
edited Apr 25 at 4:49
Elias Zamaria
1035
1035
asked Jan 10 '12 at 22:53
slitersliter
15526
15526
A number of things could be determining this, switch performance and buffer sizes, disk capabilities on either end.
– SpacemanSpiff
Jan 10 '12 at 23:00
The reason for what?
– mailq
Jan 10 '12 at 23:01
add a comment |
A number of things could be determining this, switch performance and buffer sizes, disk capabilities on either end.
– SpacemanSpiff
Jan 10 '12 at 23:00
The reason for what?
– mailq
Jan 10 '12 at 23:01
A number of things could be determining this, switch performance and buffer sizes, disk capabilities on either end.
– SpacemanSpiff
Jan 10 '12 at 23:00
A number of things could be determining this, switch performance and buffer sizes, disk capabilities on either end.
– SpacemanSpiff
Jan 10 '12 at 23:00
The reason for what?
– mailq
Jan 10 '12 at 23:01
The reason for what?
– mailq
Jan 10 '12 at 23:01
add a comment |
2 Answers
2
active
oldest
votes
There are mainly two mechanisms to reduce the amount of ACK packets returned - the Nagle algorithm and Delayed ACKs - both described in RFC 1122. Both are optional, so there will be hosts which are either configured not to use them or have the appropriate implementation missing. Especially Samba can be instructed to disable the Nagle algorithm by using socket options = TCP_NODELAY
in the configuration.
Your difference in upstream / downstream data rates for SMB file copies is likely to have other reasons than an abundance of TCP ACK packets though.
Yes, the main reason for this is the capabilities of CPU. My PC is capable of sending a packet every 12.5us average while the router sends a packet every 90us average. So, the uploading should be 7 time faster, but it didn't. That's why I think the ACK also has a quite important influence.
– sliter
Jan 10 '12 at 23:52
@sliter The number of ACKs would only influence the throughput if your router is operating at the maximum forwarding capacity regarding its packets per second performance (each received / forwarded / processed packet will obviously cost CPU performance) or if your upstream can't handle the sustained data rate needed for the ACKs. I would suggest looking into your router's/Samba server's performance metrics to check if the CPU is bottlenecking there on both occasions.
– the-wabbit
Jan 11 '12 at 21:12
add a comment |
The TCP implementation ACKs every other data packet. So you should see, typically, two data packets received and then an ACK sent. The sender, of course, is not waiting for the ACK anyway. It will continue to transmit until the window is full, even in the absence of an ACK.
There are other factors potentially at play here, such as Nagle and delayed ACK. But it doesn't look like you're seeing the affects of them.
This is exactly what I saw for the downloading, my PC ACKs after receiving two packets but not for the uploading. Besides, where the kernel's implementation for ACKing every other data packet?
– sliter
Jan 10 '12 at 23:44
What did you see during the uploading? The logic for ACKing is primarily in the__tcp_ack_snd_check
function intcp_input.c
andtcp_send_delayed_ack
intcp_output.c
.
– David Schwartz
Jan 10 '12 at 23:50
For uploading, between two ACKs, there are around 22 frames transmitted. My guess is that, for uploading the delayed ACK is activated. Because, the time between ACKs is 0.6ms which is smaller than TCP_DELACK_MAX(2ms) and larger than TCP_DELACK_MIN(0.4ms). What you think?
– sliter
Jan 11 '12 at 9:02
Even so, the window should be large enough that the ACKs shouldn't be affecting performance.
– David Schwartz
Jan 11 '12 at 19:18
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "2"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f348666%2fwhen-does-the-tcp-engine-decide-to-send-an-ack%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
There are mainly two mechanisms to reduce the amount of ACK packets returned - the Nagle algorithm and Delayed ACKs - both described in RFC 1122. Both are optional, so there will be hosts which are either configured not to use them or have the appropriate implementation missing. Especially Samba can be instructed to disable the Nagle algorithm by using socket options = TCP_NODELAY
in the configuration.
Your difference in upstream / downstream data rates for SMB file copies is likely to have other reasons than an abundance of TCP ACK packets though.
Yes, the main reason for this is the capabilities of CPU. My PC is capable of sending a packet every 12.5us average while the router sends a packet every 90us average. So, the uploading should be 7 time faster, but it didn't. That's why I think the ACK also has a quite important influence.
– sliter
Jan 10 '12 at 23:52
@sliter The number of ACKs would only influence the throughput if your router is operating at the maximum forwarding capacity regarding its packets per second performance (each received / forwarded / processed packet will obviously cost CPU performance) or if your upstream can't handle the sustained data rate needed for the ACKs. I would suggest looking into your router's/Samba server's performance metrics to check if the CPU is bottlenecking there on both occasions.
– the-wabbit
Jan 11 '12 at 21:12
add a comment |
There are mainly two mechanisms to reduce the amount of ACK packets returned - the Nagle algorithm and Delayed ACKs - both described in RFC 1122. Both are optional, so there will be hosts which are either configured not to use them or have the appropriate implementation missing. Especially Samba can be instructed to disable the Nagle algorithm by using socket options = TCP_NODELAY
in the configuration.
Your difference in upstream / downstream data rates for SMB file copies is likely to have other reasons than an abundance of TCP ACK packets though.
Yes, the main reason for this is the capabilities of CPU. My PC is capable of sending a packet every 12.5us average while the router sends a packet every 90us average. So, the uploading should be 7 time faster, but it didn't. That's why I think the ACK also has a quite important influence.
– sliter
Jan 10 '12 at 23:52
@sliter The number of ACKs would only influence the throughput if your router is operating at the maximum forwarding capacity regarding its packets per second performance (each received / forwarded / processed packet will obviously cost CPU performance) or if your upstream can't handle the sustained data rate needed for the ACKs. I would suggest looking into your router's/Samba server's performance metrics to check if the CPU is bottlenecking there on both occasions.
– the-wabbit
Jan 11 '12 at 21:12
add a comment |
There are mainly two mechanisms to reduce the amount of ACK packets returned - the Nagle algorithm and Delayed ACKs - both described in RFC 1122. Both are optional, so there will be hosts which are either configured not to use them or have the appropriate implementation missing. Especially Samba can be instructed to disable the Nagle algorithm by using socket options = TCP_NODELAY
in the configuration.
Your difference in upstream / downstream data rates for SMB file copies is likely to have other reasons than an abundance of TCP ACK packets though.
There are mainly two mechanisms to reduce the amount of ACK packets returned - the Nagle algorithm and Delayed ACKs - both described in RFC 1122. Both are optional, so there will be hosts which are either configured not to use them or have the appropriate implementation missing. Especially Samba can be instructed to disable the Nagle algorithm by using socket options = TCP_NODELAY
in the configuration.
Your difference in upstream / downstream data rates for SMB file copies is likely to have other reasons than an abundance of TCP ACK packets though.
edited Jan 10 '12 at 23:27
Skyhawk
13.5k34591
13.5k34591
answered Jan 10 '12 at 23:22
the-wabbitthe-wabbit
36.2k1181151
36.2k1181151
Yes, the main reason for this is the capabilities of CPU. My PC is capable of sending a packet every 12.5us average while the router sends a packet every 90us average. So, the uploading should be 7 time faster, but it didn't. That's why I think the ACK also has a quite important influence.
– sliter
Jan 10 '12 at 23:52
@sliter The number of ACKs would only influence the throughput if your router is operating at the maximum forwarding capacity regarding its packets per second performance (each received / forwarded / processed packet will obviously cost CPU performance) or if your upstream can't handle the sustained data rate needed for the ACKs. I would suggest looking into your router's/Samba server's performance metrics to check if the CPU is bottlenecking there on both occasions.
– the-wabbit
Jan 11 '12 at 21:12
add a comment |
Yes, the main reason for this is the capabilities of CPU. My PC is capable of sending a packet every 12.5us average while the router sends a packet every 90us average. So, the uploading should be 7 time faster, but it didn't. That's why I think the ACK also has a quite important influence.
– sliter
Jan 10 '12 at 23:52
@sliter The number of ACKs would only influence the throughput if your router is operating at the maximum forwarding capacity regarding its packets per second performance (each received / forwarded / processed packet will obviously cost CPU performance) or if your upstream can't handle the sustained data rate needed for the ACKs. I would suggest looking into your router's/Samba server's performance metrics to check if the CPU is bottlenecking there on both occasions.
– the-wabbit
Jan 11 '12 at 21:12
Yes, the main reason for this is the capabilities of CPU. My PC is capable of sending a packet every 12.5us average while the router sends a packet every 90us average. So, the uploading should be 7 time faster, but it didn't. That's why I think the ACK also has a quite important influence.
– sliter
Jan 10 '12 at 23:52
Yes, the main reason for this is the capabilities of CPU. My PC is capable of sending a packet every 12.5us average while the router sends a packet every 90us average. So, the uploading should be 7 time faster, but it didn't. That's why I think the ACK also has a quite important influence.
– sliter
Jan 10 '12 at 23:52
@sliter The number of ACKs would only influence the throughput if your router is operating at the maximum forwarding capacity regarding its packets per second performance (each received / forwarded / processed packet will obviously cost CPU performance) or if your upstream can't handle the sustained data rate needed for the ACKs. I would suggest looking into your router's/Samba server's performance metrics to check if the CPU is bottlenecking there on both occasions.
– the-wabbit
Jan 11 '12 at 21:12
@sliter The number of ACKs would only influence the throughput if your router is operating at the maximum forwarding capacity regarding its packets per second performance (each received / forwarded / processed packet will obviously cost CPU performance) or if your upstream can't handle the sustained data rate needed for the ACKs. I would suggest looking into your router's/Samba server's performance metrics to check if the CPU is bottlenecking there on both occasions.
– the-wabbit
Jan 11 '12 at 21:12
add a comment |
The TCP implementation ACKs every other data packet. So you should see, typically, two data packets received and then an ACK sent. The sender, of course, is not waiting for the ACK anyway. It will continue to transmit until the window is full, even in the absence of an ACK.
There are other factors potentially at play here, such as Nagle and delayed ACK. But it doesn't look like you're seeing the affects of them.
This is exactly what I saw for the downloading, my PC ACKs after receiving two packets but not for the uploading. Besides, where the kernel's implementation for ACKing every other data packet?
– sliter
Jan 10 '12 at 23:44
What did you see during the uploading? The logic for ACKing is primarily in the__tcp_ack_snd_check
function intcp_input.c
andtcp_send_delayed_ack
intcp_output.c
.
– David Schwartz
Jan 10 '12 at 23:50
For uploading, between two ACKs, there are around 22 frames transmitted. My guess is that, for uploading the delayed ACK is activated. Because, the time between ACKs is 0.6ms which is smaller than TCP_DELACK_MAX(2ms) and larger than TCP_DELACK_MIN(0.4ms). What you think?
– sliter
Jan 11 '12 at 9:02
Even so, the window should be large enough that the ACKs shouldn't be affecting performance.
– David Schwartz
Jan 11 '12 at 19:18
add a comment |
The TCP implementation ACKs every other data packet. So you should see, typically, two data packets received and then an ACK sent. The sender, of course, is not waiting for the ACK anyway. It will continue to transmit until the window is full, even in the absence of an ACK.
There are other factors potentially at play here, such as Nagle and delayed ACK. But it doesn't look like you're seeing the affects of them.
This is exactly what I saw for the downloading, my PC ACKs after receiving two packets but not for the uploading. Besides, where the kernel's implementation for ACKing every other data packet?
– sliter
Jan 10 '12 at 23:44
What did you see during the uploading? The logic for ACKing is primarily in the__tcp_ack_snd_check
function intcp_input.c
andtcp_send_delayed_ack
intcp_output.c
.
– David Schwartz
Jan 10 '12 at 23:50
For uploading, between two ACKs, there are around 22 frames transmitted. My guess is that, for uploading the delayed ACK is activated. Because, the time between ACKs is 0.6ms which is smaller than TCP_DELACK_MAX(2ms) and larger than TCP_DELACK_MIN(0.4ms). What you think?
– sliter
Jan 11 '12 at 9:02
Even so, the window should be large enough that the ACKs shouldn't be affecting performance.
– David Schwartz
Jan 11 '12 at 19:18
add a comment |
The TCP implementation ACKs every other data packet. So you should see, typically, two data packets received and then an ACK sent. The sender, of course, is not waiting for the ACK anyway. It will continue to transmit until the window is full, even in the absence of an ACK.
There are other factors potentially at play here, such as Nagle and delayed ACK. But it doesn't look like you're seeing the affects of them.
The TCP implementation ACKs every other data packet. So you should see, typically, two data packets received and then an ACK sent. The sender, of course, is not waiting for the ACK anyway. It will continue to transmit until the window is full, even in the absence of an ACK.
There are other factors potentially at play here, such as Nagle and delayed ACK. But it doesn't look like you're seeing the affects of them.
answered Jan 10 '12 at 23:32
David SchwartzDavid Schwartz
28.7k14474
28.7k14474
This is exactly what I saw for the downloading, my PC ACKs after receiving two packets but not for the uploading. Besides, where the kernel's implementation for ACKing every other data packet?
– sliter
Jan 10 '12 at 23:44
What did you see during the uploading? The logic for ACKing is primarily in the__tcp_ack_snd_check
function intcp_input.c
andtcp_send_delayed_ack
intcp_output.c
.
– David Schwartz
Jan 10 '12 at 23:50
For uploading, between two ACKs, there are around 22 frames transmitted. My guess is that, for uploading the delayed ACK is activated. Because, the time between ACKs is 0.6ms which is smaller than TCP_DELACK_MAX(2ms) and larger than TCP_DELACK_MIN(0.4ms). What you think?
– sliter
Jan 11 '12 at 9:02
Even so, the window should be large enough that the ACKs shouldn't be affecting performance.
– David Schwartz
Jan 11 '12 at 19:18
add a comment |
This is exactly what I saw for the downloading, my PC ACKs after receiving two packets but not for the uploading. Besides, where the kernel's implementation for ACKing every other data packet?
– sliter
Jan 10 '12 at 23:44
What did you see during the uploading? The logic for ACKing is primarily in the__tcp_ack_snd_check
function intcp_input.c
andtcp_send_delayed_ack
intcp_output.c
.
– David Schwartz
Jan 10 '12 at 23:50
For uploading, between two ACKs, there are around 22 frames transmitted. My guess is that, for uploading the delayed ACK is activated. Because, the time between ACKs is 0.6ms which is smaller than TCP_DELACK_MAX(2ms) and larger than TCP_DELACK_MIN(0.4ms). What you think?
– sliter
Jan 11 '12 at 9:02
Even so, the window should be large enough that the ACKs shouldn't be affecting performance.
– David Schwartz
Jan 11 '12 at 19:18
This is exactly what I saw for the downloading, my PC ACKs after receiving two packets but not for the uploading. Besides, where the kernel's implementation for ACKing every other data packet?
– sliter
Jan 10 '12 at 23:44
This is exactly what I saw for the downloading, my PC ACKs after receiving two packets but not for the uploading. Besides, where the kernel's implementation for ACKing every other data packet?
– sliter
Jan 10 '12 at 23:44
What did you see during the uploading? The logic for ACKing is primarily in the
__tcp_ack_snd_check
function in tcp_input.c
and tcp_send_delayed_ack
in tcp_output.c
.– David Schwartz
Jan 10 '12 at 23:50
What did you see during the uploading? The logic for ACKing is primarily in the
__tcp_ack_snd_check
function in tcp_input.c
and tcp_send_delayed_ack
in tcp_output.c
.– David Schwartz
Jan 10 '12 at 23:50
For uploading, between two ACKs, there are around 22 frames transmitted. My guess is that, for uploading the delayed ACK is activated. Because, the time between ACKs is 0.6ms which is smaller than TCP_DELACK_MAX(2ms) and larger than TCP_DELACK_MIN(0.4ms). What you think?
– sliter
Jan 11 '12 at 9:02
For uploading, between two ACKs, there are around 22 frames transmitted. My guess is that, for uploading the delayed ACK is activated. Because, the time between ACKs is 0.6ms which is smaller than TCP_DELACK_MAX(2ms) and larger than TCP_DELACK_MIN(0.4ms). What you think?
– sliter
Jan 11 '12 at 9:02
Even so, the window should be large enough that the ACKs shouldn't be affecting performance.
– David Schwartz
Jan 11 '12 at 19:18
Even so, the window should be large enough that the ACKs shouldn't be affecting performance.
– David Schwartz
Jan 11 '12 at 19:18
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f348666%2fwhen-does-the-tcp-engine-decide-to-send-an-ack%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
A number of things could be determining this, switch performance and buffer sizes, disk capabilities on either end.
– SpacemanSpiff
Jan 10 '12 at 23:00
The reason for what?
– mailq
Jan 10 '12 at 23:01