Log in Register FAQ Memberlist Search pcHDTV Forum Index
pcHDTV Forum

pcHDTV Forum Index -> HD-2000/3000 drivers -> Athlon64 and QAM driver issues Goto page 1, 2  Next
Post new topic  This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic 
Athlon64 and QAM driver issues
PostPosted: Tue Nov 08, 2005 7:18 pm Reply with quote
pridkett
 
Joined: 22 Oct 2005
Posts: 13




I've had my pcHDTV card for a few months but only recently started to play with it earnest. At the time I had it an Athlon 700 MHz machine and it was able to record over QAM just fine. In fact, as a test, a few weeks ago I recorded the HDTV version of Monsters, Inc in all of it's beautifulness, this plays back 100% flawlessly with our without XvMC (just a difference in CPU load).

Then, fortunately or unfortunately, the 700MHz machine died. I upgraded to an athlon 64 3200+. I've managed to get the drivers going again (not much work under Ubuntu Breezy, 2.6.12-9-amd64 kernel) and IVTV loads with it too (just remember to load IVTV first). However, I've noticed that where before I would not get corruption on the saved files, now I get corruption, once every few seconds or so. This makes it rather annoying and not of the best quality. I'm also experiencing some sound quality issues over time.

Is there a possibility that the jump from 32bit to 64bit did something to the driver that makes it not pick up QAM as well anymore? Under 32bit I was running basically the same exact kernel, but as 32bit (2.6.12-9-k7) and IVTV still worked.

I've noticed that occasionally it will say that it's lost the lock when looking at the azap output, but I get more glitches than from just loosing the lock. I know I can get decent quality HDTV because I can tune the cable box over firewire and get perfect HDTV.

Have changes been made in newer kernel versions that might solve this? Today I tried picking up a signal amplifier that was HD compatible from radio shack and it didn't do anything. Should I just invest in an antenna?

Thanks!

Patrick

Here's my system info FWIW:
AMD Athlon 64 3200+
MSI K8N-Neo4 Platinum Mobo
GeForce 6600
1GB Kingston Ram
Ubuntu Breezy (5.10)
pcHDTV HD-3000
WinTV PVR-250
View user's profile Send private message
possible interference from IDE controllers
PostPosted: Tue Nov 08, 2005 10:02 pm Reply with quote
pridkett
 
Joined: 22 Oct 2005
Posts: 13




I found a thread http://www.gossamer-threads.com/lists/mythtv/users/159591 on the MythTV users site discussing some of the issues related to DVB corruption. Apparently lots of folks have Silicon Image onboard controllers and are having issues. I too have a Silicon Image controler on my motherboard.

I went through and disabled the SiI controller and still didn't improve the output. I also tried saving to ramdisk, and still had problems. In fact, it seems to have gotten worse.

However, I have noticed one VERY interesting thing: when I start to record, signal level drops noticeably, from f8ca area (I think) to cxxx and dxxx levels (where xxx varies over time). This suggests that there may be a bus related issue and also explains why the card could record just fine on my old machine.
View user's profile Send private message
More followup information
PostPosted: Wed Nov 09, 2005 6:25 am Reply with quote
pridkett
 
Joined: 22 Oct 2005
Posts: 13




Just a bit more followup information. I can confirm that my machine has no problem displaying HD content back, as I'm able to capture and watch live TV over the firewire port without any glitches.

Furthermore, I had no problem last night capturing HDTV and not watching it back while still recording. I can say with some degree of certainty that the interference is related to I/O on the system. Other people on the MythTV mailing list thread seem to think the same thing.

Any ideas on what I can do to make this better? I'd rather not have to go get a new motherboard, after all, this one is only a week old.
View user's profile Send private message
PostPosted: Wed Nov 09, 2005 7:58 am Reply with quote
GrepTar
 
Joined: 10 Jan 2005
Posts: 51




Have you tried it w/o the pvr card and not loading ivtv? I had problems recording hdtv until I got rid of the pvr card.
View user's profile Send private message
PostPosted: Wed Nov 09, 2005 7:48 pm Reply with quote
pridkett
 
Joined: 22 Oct 2005
Posts: 13




While I haven't taken the IVTV card out of the system, I can say with virtual certainty that it is not IVTV related. My reason is because I can record HDTV just fine when I'm not trying to watch it at the same time. Today I had it set up to record a couple of programs while I was out and not watching anything and the output was just fine.

However, I just tried some HD programs while my wife was doing other disk activity (watching some prerecorded standard def streams) and sure enough, they were corrupted. The only variable that changed was that in case 2 there was additional disk IO and CPU load from decoding videos. I think I can safely cancel

I'm fairly certain there is a direct tie between disk activity and the amount of corruption I'm seeing here. I think I can safely nix the CPU load issue. Furthermore, I'm pretty certain that the issues are not with my hard drive because I can capture and watch while capturing HDTV off the firewire on my cable box.

Given the recent talk on the MythTV mailing list, it's becoming clear that the common denominator is disk activity. The strange thing is that I don't even have the SATA chipset enabled on my motherboard unlike other people who were quick to blame it on the Silicon Image SATA chips. I'll try a newer kernel version this weekend and post a followup.
View user's profile Send private message
PostPosted: Fri Nov 11, 2005 7:56 am Reply with quote
pridkett
 
Joined: 22 Oct 2005
Posts: 13




I removed the IVTV card and drivers, reverted back to the original stock 2.6.12 drivers for the HD3000 and can confirm that the problem persists. I can safely eliminate IVTV as the source of the problem. It persists with and without.

It definately seems to be a load issue. Recording off the tuner when nothing else is happening works just fine. Load of any moderate amount (including watching the stream while recording) causes digital static. My system can handle the IO necessary for this, because I have no problem watching a live stream in MythTV from the DCT6200 cable box on firewire.

It's one of two things:

1) hardware issue. Not my card, many people have this problem. Some sort of weird interaction.

2) driver issue. No idea where to start here.
View user's profile Send private message
PostPosted: Sat Nov 12, 2005 12:56 pm Reply with quote
pridkett
 
Joined: 22 Oct 2005
Posts: 13




More followup, installed i386, still exhibits some problems, although it seems to be less. Still much more static than what I get over the cable box.
View user's profile Send private message
PostPosted: Mon Nov 14, 2005 9:27 pm Reply with quote
goertzm
 
Joined: 14 Nov 2005
Posts: 1




I don't have a pchdtv card, but I have been thinking about getting one for a while. In any case, I don't know if this will help you but I experienced a similar behavior on an older MSI Athlon MB with a 1.4GHz athlon. I could record from my PVR-250 card no problem, but if I watched the stream at the same time, or otherwise loaded the system, I would get corruption and sometimes crashing. It was a bios setting problem, specifically, there was an option for clock spread spectrum to reduce EMI and it was enabled. Well it seems the additional jitter on the clocks was hosing the system, and making the whole thing unreliable. If you can't seem to put your finger on software, it could be a bios problem. Can you create strange behavior by loading the system up with video playback and some other disk intensive activities? That could rule out the pcHDTV card and drivers.
View user's profile Send private message
PostPosted: Wed Nov 16, 2005 3:53 pm Reply with quote
pridkett
 
Joined: 22 Oct 2005
Posts: 13




Thanks for the tip about spread spectrum on the board, but it doesn't appear to have helped. I tried checking out some other interference related issues by doing the following:


  • moving the pchdtv to the "communications" PCI slot on the board. This is a slot on the far side of the board, colored in orange that can take MSI all in one wireless card. It's also supposed to have extra shielding for intereference. No difference for me.
  • changing hyperthreading from 16 (default) each way to 8 each way
  • varying the hyperthreading multiplier from 1x to 5x (default)
  • lowering FSB speed
  • combinations of the above three


In all of these cases it still causes reception to drop down quite when I start recording and further drop down when I start playing it back. I did notice that I was able to induce some errors on my wintvPVR250 doing some of these tests, so this indicates that it's interference. Stupid motherboard.
View user's profile Send private message
PostPosted: Wed Nov 23, 2005 11:23 pm Reply with quote
CMStech
 
Joined: 23 Nov 2005
Posts: 3




Wow, I kept asking myself if I had posted this as I read through it.

I am having the exact same problem with the exact same hardware.

My Specs:
AMD Athlon 64 3200+ (Dual Core)
MSI K8N-Neo4 Platinum Mobo
GeForce 6600
2 Gig Ram
1 Terabyte HD Space
FC4 x86
pcHDTV HD-3000


I will try some different BIOS settings and see what happens.
View user's profile Send private message
PostPosted: Sun Nov 27, 2005 6:55 pm Reply with quote
pridkett
 
Joined: 22 Oct 2005
Posts: 13




So I've been taking other folks advice and seeing about the interference issue from the motherboard, and I can tell you that it does not appear to be specific to just this motherboard. I just purchsed and ASRock 939 Dual SATA2 motherboard to test it on, based on good reviews from folks. Sure enough, as I/O load increases, reception goes bad. It doesn't even matter if I'm working on the same disks or not, it seems to be any sort of I/O that drops the reception.

Here's an interesting log of the signal strength as I record:
Code:

patrick@spongebob:~/src/dvb-apps$ ./util/szap/azap WTAE-DT
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 537000000 Hz
video pid 0x0800, audio pid 0x0801
status 1f | signal f3f6 | snr f7e3 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd41 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd59 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd2f | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd3d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd19 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd0f | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd0d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd73 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd65 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd31 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fcfd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd13 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd5b | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fcfd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd5f | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd67 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd43 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd31 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd27 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd27 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd4d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd39 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fdf2 | snr fd37 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd2b | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd3d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd53 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd35 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd1b | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd23 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd47 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd5d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd39 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd43 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
**1** status 1f | signal ef9c | snr fd35 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd33 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal eb42 | snr fd39 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd35 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd51 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd33 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr 24ba | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd59 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd1b | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd1b | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd37 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fcf7 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd31 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd53 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd49 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd61 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd47 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd47 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd17 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd67 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal ef9c | snr fcfd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd3b | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd05 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd15 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd61 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd4d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd37 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal ef9c | snr fd45 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal ef9c | snr fd4f | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd4d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd43 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
**2** status 1f | signal eb42 | snr fcfb | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal ef9c | snr fd29 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal e394 | snr fc6d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd0d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal ef9c | snr fd11 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal dfff | snr fd21 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal eb42 | snr fd13 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal eb42 | snr fcc3 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal ef9c | snr fd23 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal eb42 | snr fcb1 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal ef9c | snr fcb1 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd2f | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd19 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fd0f | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fcc3 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal e394 | snr fd23 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fd0d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f3f6 | snr fcb7 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal e394 | snr fd0b | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal f8d4 | snr fcff | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 00 | signal ef9c | snr fcaf | ber 00000000 | unc 00000000 |
status 1f | signal eb42 | snr fccf | ber 00000000 | unc 00000000 | FE_HAS_LOCK


The line that starts **1** is when I started to record the stream. Notice the drop in signal strength almost immediately, but how it ramps back up some. The line that starts **2** is when I started watching the stream as it was being recorded. The video was mostly fine up until I got to XX seconds in (where XX is the time between **1** and **2**), after this point, there was noticeable and severe digital static.

To do a bit more debugging, I decided to see what would happen if the storage was off system. So I plugged my laptop into a wired connection and set up an NFS share between the systems. I then had the system with the pcHDTV HD-3000 card record the program and save it over NFS to the laptop. If I tried to watch the program over the NFS mount on the machine with the pcHDTV HD-3000 then I got severe corruption. However, when I stopped watching the program on the pcHDTV box and started watching it on the laptop the corruption disappeared and the program worked fine.

It's fairly clear that there is a direct correlation between activity on several different motherboards (at least two that I have tested) and poor signal reception. This is not just disk activity, but also network activity too.

My hunch, based on my BS level of electrical engineering knowledge that I don't use anymore is that the increased bus activity is creating some EMI that is interfereing with the pcHDTV's tuning capability. When there is little noise, it's fine, however when more noise is present it causes errors in the receiving of the signal and transfer onto the PCI bus.

So, for the pcHDTV techs, any hot solutions on how to minimize EMI? I've tried the whole spread spectrum thing with basically no luck.
View user's profile Send private message
PostPosted: Tue Nov 29, 2005 7:13 pm Reply with quote
pcHDTV_tech
 
Joined: 16 Dec 2004
Posts: 295




Just a thought or two:

Since the signal level drops and corruption happens when you watch and record at the same time on the same machine, it could be that your power supply is marginal and the increase in activity (video card, disk access, etc.) is actually dropping the voltage on the PCI bus.

EMI could be an issue, but I'm doubtful that would show up as decreased signal levels. A voltage drop on the bus could result in data errors in the received stream.

HTH,

Rusty
View user's profile Send private message Visit poster's website
PostPosted: Sat Jan 14, 2006 9:41 am Reply with quote
pridkett
 
Joined: 22 Oct 2005
Posts: 13




pcHDTV_tech wrote:
Just a thought or two:

Since the signal level drops and corruption happens when you watch and record at the same time on the same machine, it could be that your power supply is marginal and the increase in activity (video card, disk access, etc.) is actually dropping the voltage on the PCI bus.

EMI could be an issue, but I'm doubtful that would show up as decreased signal levels. A voltage drop on the bus could result in data errors in the received stream.

HTH,

Rusty


I never thought about the power supply issues. Know of a way I can check to see what the voltage is on the PCI bus while it's running (short of cracking open the case and plugging a multimeter into some wires). I've got a reasonably good Antec powersupply (part of Antec Overture II), so I'm doubtful that's the problem, but it could explain it. Also, it could just be a result of QAM related issues, at it seems other people are experiencing similar problems, as shown in this thread.

I'd like to try antenna, but even though I'm close to the towers, the hills in Pittsburgh make this rather difficul. I suppose I could just climb on the roof though. Anecdotal evidence on the MythTV-Users list, suggests it may be QAM related though
View user's profile Send private message
Tried a different file system?
PostPosted: Sat Jan 14, 2006 3:53 pm Reply with quote
maestro
 
Joined: 10 Jul 2004
Posts: 18




pcHDTV_tech wrote:

Since the signal level drops and corruption happens when you watch and record at the same time on the same machine, it could be that your power supply is marginal and the increase in activity (video card, disk access, etc.) is actually dropping the voltage on the PCI bus.

EMI could be an issue, but I'm doubtful that would show up as decreased signal levels. A voltage drop on the bus could result in data errors in the received stream.


I had a similar problem when recording and watching (Threshold) months ago. There were also numerous cxXXXX "Buffer overruns" in the error log (dmesg IIRC). It turns out that ext3 couldn't handle the I/O pressure. Since I switched to XFS, I've never had a glitch. (If you know how partitions work and can use growfs and dd, you can keep your files if you have less than 50% disk usage.)

This was all OTA however, so you may well have a different issue.
View user's profile Send private message
Did you ever find a solution?
PostPosted: Sun Feb 19, 2006 6:09 pm Reply with quote
myrkle
 
Joined: 19 Feb 2006
Posts: 1




pridkett wrote:

I never thought about the power supply issues. Know of a way I can check to see what the voltage is on the PCI bus while it's running (short of cracking open the case and plugging a multimeter into some wires). I've got a reasonably good Antec powersupply (part of Antec Overture II), so I'm doubtful that's the problem, but it could explain it. Also, it could just be a result of QAM related issues, at it seems other people are experiencing similar problems, as shown in this thread.

I'd like to try antenna, but even though I'm close to the towers, the hills in Pittsburgh make this rather difficul. I suppose I could just climb on the roof though. Anecdotal evidence on the MythTV-Users list, suggests it may be QAM related though


I am having the same problems, and I too have an Antec Overture II. I begin to wonder whether the power supply is indeed the issue. Did you ever wind up solving your problems?

Has anyone had any luck using the Antec Overture II and its powersupply with the HD-3000?
View user's profile Send private message
Athlon64 and QAM driver issues
  pcHDTV Forum Index -> HD-2000/3000 drivers
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT - 7 Hours  
Page 1 of 2  
Goto page 1, 2  Next
  
  
 Post new topic  This topic is locked: you cannot edit posts or make replies.  


Powered by phpBB © 2001-2003 phpBB Group
Theme created by Vjacheslav Trushkin